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COMPUTERS IN SCIENCE & ART 


A 132 page Catalog of unique, hard-to-find 
Educational & Entertaining 
Software, Books, Videotapes, and CD-ROMs. 
Featuring: 27 books, 8 videotapes, magazines, 
and software programs on Virtual Reality. 


Request a free copy! 
MEDIA MAGIC PO Box 598-pcvr Nicasio, CA 94946 
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Subscriptions are $26.00 US/Canada ($38.00 Foreign) 


We have Back Issues of PCVR Magazine Available! 
Just mark the ones you want and mail today! 


Copies of Issue 1 - Power Glove Hardware 
Copies of Issue 2 - Power Glove Software 
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Getting in Touch with Us 


PCVR Magazine feels that its success is 
mainly due to our readers. We are 
always interested in what you have to 
say and are more than willing to answer 
your questions on a variety of subjects. 
We are also open to constructive 
criticism. 


Our mailing address is PCVR Maga- 
zine, PO Box 475, Stoughton, WI 
53589. 


Our telephone number is 608-877-0909 
and our fax number is 608-877-0909. 
The fax machine is on an automated 
switch. If your machine does the 
calling, the switch will be activated 
automatically. If you use your fax 
phone to dial our fax machine, press 1 
followed by a 9 to reach the fax ma- 
chine. 


Electronic Mail 

The publisher of PCVR Magazine 
maintains several Internet email ad- 
dresses: 


70711.257@compuserve.com 
PCVR@FullFeed.COM 


Bulletin Board 

PCVR Magazine makes all magazine 
source code available to our readers and 
others through our BBS. The data 
number is 608-877-1017. The board 
operates on a single line with a 14.4k 
baud modem and is operational 24 hours 
a day. 


The board contains a complete file and 
message system for access to a wide 
variety of information. If you are 
having a problem with something, feel 
free to give our BBS a call and find out 
if others have had the same problem. 
You may even find the solution you 
were looking for. 
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7 Designing Heavy Objects 
Using very simple software techniques, we can design virtual objects that have weight. 
We can use a Power Glove to pick them up and watch them fall. 


. 11° Mouse Tactors 


Using a three-dimensional mouse from Logitech and a simple feedback device called 
a Tactor, the authors create an interesting input device. 


14 Thermal Feedback 


One feedback mechanism that has always been missing from virtual worlds is 
thermal feedback. CM Research shows us that thermal feedback has been achieved. 


19 Feedback Devices 


We take a quick look at companies who are creating feedback devices including 
thermal, force, and tactile feedback. 


20 Cyberterm - Part 3 


Michael Snoswell ends his three part series on the cyberspace product - Cyberterm. 
Read how the BBS system is developing and where it can be downloaded. 


. . 26 Towards Real Standards in Virtual Reality 


If you thought creating standards for a new programming language was hard, you 
should see how Bob Pendleton begins a possible VR standard. 


: 35. VGA-TO-NTSC Conversion 


The VGA signal is not very helpful when using VR equipment. This signal has to be 
converted to NTSC - the American standard. We look at both hardware and sofware. 


35 VR-386 


Dave Stampe has announced that he will be creating a new renderer based on the 
remains of REND386. Here is the scoop. 
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NEED INTERFACES?? 


Let Us Develop Your Virtual Reality Interfaces!!! 


PCVR Magazine introduces four interface packages for those who don't have the time to build them. 


Power Glove Interface 


Cost: $20.00 + $2.50 shipping ($4.50 Overseas) 
Includes: 
Power Glove to PC Parallel Port connector with 
external power supply plug (A +5V power 
source is necessary to use the interface) 
Disk with examples including source code 
Please Note: The interface requires a power 
supply. (see next item) 


+5v Power Supply 
Cost: $20.00 + $5.00 shipping ($20.00 Overseas) 


Power Glove 


Cost: $25-$45 + $5.00 shipping ($26.00 Over- 
seas) 

The cost of the Power Glove will fluctuate 
depending on current market prices. 


Shutter Glasses Interface 
Cost: $30.00 + $3.50 shipping ($5.50 Overseas) 
Includes: 


Shutter Glasses to PC Serial Port connector 
Disk with examples including source code 








Stuntmaster Interface 
Cost: $30.00 + $3.50 shipping ($5.50 Overseas) 
Includes: 
Complete cable for interfacing the VictorMaxx 
Stuntmaster Headset to: 
* NTSC Signal 
* Power Supply supplied with headset 
* Stereo plug for SoundBlaster or compatible 
stereo sound card 
* Head tracking through joystick game port. 
Please note that the head tracking 
consists of look right, look forward, 
and look left. There are no 
positions between these. 
Disk with examples including source code 


SIMPLE-TRACK 


This is an experimental head tracker that is not meant for professional use. The 
tracker is offered in several different configurations: 


Simple Track - Assembled - $75.00 + $6.50 Shipping ($26.00 Overseas) 

This assembled head tracker includes the complete tracker and a portable arm 
attachment as well as the software necessary to access the tracker. Example programs 
are provided for REND386 and the Lepton Renderer. A 3D model (yaw, pitch, roll) 
uses both joystick ports of the PC, the 2D model (yaw, pitch) only uses one joystick 
port. Please specify 2D or 3D model when ordering. 


Simple Track - Kit - $35.00 + $4.50 Shipping ($10.00 Overseas) 
The Simple Track (tm) kit includes all of the parts necessary for building the 
tracker except the arm. The L-Brackets are drilled and ready to assemble. 


PCVR Magazine 


PO Box 475 


Stoughton, WI 53589 
(608) 877 - 0909 tel/fax 


Accepts 
VISA, Mastercard 
American Express and 
Check or Money Order 
(must be drawn on US Funds from US Bank) 





WATS NOW 





Sense8 Corporation has released 
initial results from its beta test of 
their new product, WorldToolKit 
for Windows. "The number of 
developers who signed up for the 
Beta program in its first three 
months exceeded our expectations. 
Especially noteworthy is the fact 
that many of these customers have 
not used VR tools previously, 
which demonstrates that Sense is 
reaching anew market segment. It 
is also significant that the group 
contains a high percentage of Win- 
dows users developing desktop 
- and VR applications for re-sale. 
We interpret this to mean that 
WorldToolKit for Windows is 
meeting a real need in the Win- 
dows community and is helping 
people accomplish a range of 
tasks." says Tom Coull, president 
of Sense8. 


Sense8 Corporation 
1001 Bridgeway, #477 
Sausalito, CA 94965 

415-331-6318 tel 
415-331-9148 fax 


Logitech has announced the avail- 
ability of the Cyberman™. A 6 
Degree of Freedom input device, 
the Cyberman™ retails for $129.00 


Logitech 
6505 Kaiser Dr. 
Fremont, CA 94555 
510-795-8500 tel 
510-792-8901 fax 


RPI Advanced Technology 
Group introduces a dual VGA 
card for the PC. The VGA2x™ is 
a low-cost solution to the problem 
of stereo signal output from the 
PC. Volume pricing starts at 
under $1000.00. 


RPI 
PO Box 14607 
San Francisco, CA 94114 
415-495-5671 


IWERKS, a leading producer of 
movie-based specialty theaters re- 
cently began trading stock on 
NASDAQ. Although not true 
Virtual Reality, the trading of the 
company gives the VR industry 
hope. The company opened with 
their stock trading at $18.00 a 
share. By the end of the first hour, 
the price has ran up to $33.00 a 
share. Apparently the stock was 
so hot that the demand for the 
stock was significantly more than 
the initial offering. 


Iwerks Entertainment 
4340 W. Valerio Street 
Burbank, CA 91505-1046 
818-841-7766 

~ $18-841-7847 


Virtual Reality and Persons with 
Disabilities. Second Annual In- 
ternational Conference, Co-Spon- 
sored by IEEE and CENTER ON 
DISABILITIES, California State 
University, Northridege, June 8- 
10, 1994 San Francisco Airport 
Marriott Hotel. For Information: 


Dr. Harry Murphy 
TEEE/CSUN Conference 
California State Univ, 
Northridge 
18111 Nordhoff Street 
Northridge, CA 91330-8340 
(818) 885-2578 
(818) 885-4929 Fax 
VR@VAX.CSUN.EDU email 


Mondo-tronics, Inc. has intro- 
duced a book and deluxe sample 
kit for $59.95 which allows the 
owner to experiment with muscle 
wires. Muscle wires are metal 
filaments that contract when pow- 
ered and lift thousands of times 
their own weight. The Deluxe 
package includes a computer guide 
to designing, building, testing, and 
operating dozens of working de- 
vices, crimps and one meter each 
of 50, 100 and 150 um diameter 
Muscle Wires. 


Mondo-tronics Inc. 
524 San Anselmo Ave, #107 
San Anselmo, CA 94960 
415-455-9330. tel 
415-455-9333 fax 
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WRAT'S NOW 


Small Business Innovation Re- 
search program has released their 
new guide which includes four 
topics on Virtual Environments. 


The topics are: 


8.15.13 SUBTOPIC: Virtual En- 
vironments for Information Ac- 
cess 


8.15.14 SUBTOPIC: Virtual Re- 
ality and Manufacturing 


8.15.15. SUBTOPIC: 
Virtual Environments 


Friendly 


8.15.16 SUBTOPIC: Standard In- 
terface for Virtual Environments 


For more information: 


Dr. Joseph M. Bishop 
DOC SBIR Program Manager 
1315 East-West Highway 
Room 15342 
Silver Spring, MD 20910 
(301) 713-3565 


Lepton Graphics Systems has 
announced the availability of their 
Affordable Virtual Reality Toolkit. 
The toolkit is an affordable and 
powerful virtual reality applica- 
tion framework for '386+ PCs. It 
provides a library of over one 
hundred C-callable functions that 
speed and simplify the process of 
writing virtual reality and interac- 


tive 3D graphics programs. It 
includes drivers for many afford- 
able input and output devices. 


Lepton Graphics Systems 
2118 Central Ave SE, Suite 45 
Albuquerque, NM 87106 
505-843-6719 tel 
505-843-9394 fax 


VREAM has enhanced their Vir- 
tual Reality development package 
by adding network support. Pre- 
sented at the recent New York VR 
Expo, the new system includes 
drivers for NetBIOS as well as 
serial support through a null mo- 
dem cable. 


VREAM 
2568 N. Clark Street, 
Suite 250 
Chicago, IL 60614 
312-477-0425 tel 
312-477-9702 fax 


Spectrum Dynamics, a supplier 
of virtual reality equipment has 
recently been awarded $100,000 
to develop an immersive VR sys- 
tem for the Omniplex Science 
Museum in Oklahoma City. 


Spectrum Dynamics 
2 Greenway Plaza, Suite 640 
Houston, TX 77046 
716-520-5020 


VictorMaxx has announced a new 
HMD specifically designed for the 
PC. The Cybermax will include 
two color active matrix liquid crys- 
tal displays, proprietary optics with 
a total view of field of 70 to 80 
degrees, and sourceless 3DOF 
tracking. The product was re- 
cently demonstrated to software 
developers at the Consumer Elec- 
tronics Show in Las Vegas. The 
HMD is expected to be released 
late Spring at a price point below 
$400.00. 


VictorMaxx 
3501 Woodhead Drive, Suite 3 
Northbrook, IL 60062 


Borland International has 
released version 4.00 of their 
flagship product Borland C++. 
This long awaited new version 
hosts a new Windows based IDE 
and support for 32-bit Windows 
application development only. 
Those hoping for DOS 32-bit 
protected mode support will be 
disappointed since it is notice- 
ably absent. We hope to have a 
complete review of the new 
compiler in the next issue. 


Borland International 
PO Box 660001 
Scotts Valley, CA 95067-0001 
408-461-9000 
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Designing Heavy 
Virtual Objects 


Joe 
Gradecki 


s you spend moreand more 

time using the technology 

of Virtual Reality, you find 

that the need for a more 

realistic world becomes stronger and 

stronger. One of the ways to create 

more realism is to give objects in the 

virtual world physical characteristics 
that they possess in the real world. 

This seemingly simple concept can 

provide even the most experienced de- 

veloper with a mind full of headaches. 

One of the characteristics that has been 

partially overcome is weight. Through 


tion so the user is able to grip their real 
hand only slightly for a hard object. A 
soft object would allow the user to grip 
their hand considerably more than the 
hard object. 

All of this is fine except actually 
constructing a piece of hardware like 
those used commercially (mostly in 
laboratories) is definitely beyond our 
means. So we need to look at modeling 
characteristics of objects in a different 
way, that can be done within a budget. 


This seemingly simple concept can provide even the most 
experienced developer with a mind full of headaches 


Joe Gradecki is publisher of 
PCVR Magazine and has 
dedicated himself to the 
development of PC-Based 
Virtual Reality. 


the use of specialized hardware, a vir- 
tual object can give the participant in the 
virtual world force feedback. 

Most versions of force feedback seen 
today consist of systems that allow a 
user to grab a virtual object and the 
object will have a degree of hardness to 
it. The user will have a mechanical 
contraption wrapped around their hand 
that is controlled by the computer ex- 
ecuting the virtual world. When the 
user grabs the virtual object and squeezes 
it, the computer can adjust the contrap- 


Weight 


The characteristic that I wish to look at 
is weight. Those of you who have been 
with us for a while will recognize the 
name John Williamson. Sometime ago 
he mentioned to me that he would like 
to have a program that used the Power 
Glove to pick up virtual objects. He 
wanted me to give the virtual objects 
different weights by adjusting their 
rates of movement. 

The basic idea is this. Let’s say that 
we have three objects, called C1, C2, 
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and C3, sitting ona virtual floor. We 
want object C1 to be light, object C2 to 
be heavier, and object C3 to be the 
heaviest. 

Now in the real world, when we go to 
pick something up, its weight is a direct 
response from our muscles. If the 
object is heavy, just about every muscle 
from our hands to our feet will tell our 
brain that the object is heavy. When we 
pick up a light object, our leg muscles 
really don’t tell us anything, the brain 
relies on our hand and arm muscles. 

In addition to our muscles, we pre- 
judge the weight of an object before we 
even pick it up based on visual cues. If 
the object look heavy then it probably 
is. So, when we look at an object and 
it looks heavy, our brain tells our 
muscle that we are just about to pick up 
a heavy object. Our muscle respond 
appropriately. 

All of this brings us back to the force 
feedback mechanism we mentioned at 
the beginning of the article.. There is 
no way we are going to be able to 
restrict our muscles virtually in the 
same manner that they are in the real 
world. 

However, as John pointed out to me, 
we can add weight to objects by limiting 
the speed at which we can lift the object. 
This limiting combined with the visual 
cues of the object slowly rising, should 
be good enough for our brain to think 
we are lifting a heavy object. 

In order to see how the speed tech- 
nique works, we need to assume that we 
have a virtual hand in our virtual world 
and a way to control it. As we will see 
later, a Power Glove will be used as the 
controlling mechanism in our demon- 
stration program. 


c = pointer_read(d, p); 
if ((c & (PNEW_POS | PNEW_ROT | PNEW_FLEX)) == 0) 

return 0; 
abs_move_segment(wrist_seg, p->x, p->y + Y_GLV_OFFSET, p->z + GLOVE. DIST); 


Input 

When the renderer polls the controlling 
mechanism it converts the amount of 
movement of the controller into a spe- 
cific number of world units to move the 
virtual hand. We will take control of 
the conversion by looking at the object 
the virtual hand is holding and putting 
in our own values for the movement of 
the virtual hand. 

Let’s go back to our objects. Ifwe are 
interacting in our virtual world,. the 
virtual hand will move at a normal 
speed. This normal speed represents 
the natural movement of our real hand 
and could be expressed as say 144 
units/second. If we go over.to object 
C1, the light object, grab it, and begin 
to move our virtual hand, the system 
will determine that we are moving the 
light object and will put a slight drag on 
the movement of our hand. This slight 
drag is accomplished by slowing down 
the speed of our hand to say 135 units/ 
second. Visually, we would see that 
our virtual hand moves just about as 
much as our normal hand does when- 
ever we move our controlling mecha- 
nism. 

If, for instance, we were controlling 
our virtual hand with the mouse, a 
sweep of the mouse forward would not 
move the virtual hand which is holding 
the light cube as fast as the virtual hand 
by itself. 

Now if we dropped the light object 
and moved over to object C3, the heavy 
object, we will get an entirely different 
reaction. Once we pick up the object, 
the system will determine that we have 
the heavy object and slow our hand 
movement down to something like 35 


Figure 1 


units/second. This would be a signifi- 
cant reduction in speed which would 
translate visually toa very slow moving 
hand even though we are moving our 
controlling mechanism the same dis- 
tance as we did for the virtual hand by 
itself. 


Software 

When the prototype software for this 
virtual weight problem was developed, 
a mouse was used to control the virtual 
hand. The effect of the weight simula- 
tion seemed to be lost when using the 
mouse because to lift the heavy object, 
one would have to continually move the 
mouse forward, pick it up, move it toa 
new position, and push forward again. 
Remember that each forward move- 
ment of the mouse was 25% efficient 
when holding the heavy object. 

The next logical step was to imple- 
ment the weight simulation using the 
Power Glove. I chose to make some 
simple changes in the REND386 Power 
Glove driver in order to implement 
different object weights. 

There are two main areas of change. 
The first is in the translation from the 
Power Glove units to the units of the 
virtual hand and the second area of 
change is allowing the virtual hand to 
pick up an object. 


Translation 

When the Power Glove mechanism is 
added to a REND386 program, the 
following two lines (top of next page) 
are put into the program's main loop. 
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glove _update( manip device, &gp ); 
update segment ( body_seg ); 








The first line calls the code that controls 
the interface with the Power Glove and 
makes all of the changes to the virtual 
hand object. The second line makes the 
changes to the object valid. We need to 
go into the glove update routine and 
see what’s happening. Figure 1 shows 
the beginning part of the routine. 

The routine begins by calling the 
routine pointer_read to get a current 
reading from the glove. The data 
structure pointed to by the variable P is 
filled with the glove information. Upon 
return from the read routine, we deter- 
mine if a change has been made in the 
position of the glove. If no change is 
made, then we don’t need to make any 
changes to the virtual hand. 

If a change has taken place, we per- 
form an absolute move on the segment 
representing the virtual hand. 

The code works fine for its intended 
purpose but if we want to add code for 
weight, we must be able to position the 
virtual hand some calculated distance 
from its previous position. In other 
words, we need to be able to make 
relative movements to the virtual hand 
and not absolute movements. 

Remember that absolute movements 
simply place the virtual hand at some 
desired location whereas relative move- 
ments place the virtual hand some de- 
sired distance from the current loca- 
tion. 


c = pointer_read(d, p); 
if ((c & (PNEW_POS | PNEW_ROT | PNEW_FLEX)) == 0) return 0; 


if (!heavy) 





The changes made to this routine are 
shown in Figure 2. 

As you can tell, the change we have 
made to the routine is very subtle. The 
first thing we do is introduce a new 
global variable called HEAVY that is 
initialized to O upon program execu- 
tion. This variable is used to determine 
if an object has a particular weight to it 
and how much. 

When the program first executes, the 
glove routine will read the current po- 
sition of the glove as it did before we 
changed the routine. After the glove is 
read, the system checks the current 
value of the HEAVY variable. If 
HEAVY is set to 0, the program will 
process the glove movement exactly as 
before using an absolute movement 
statement. If HEAVY is set to any 
other value, the system will execute a 
relative movement statement. It’s this 
movement statement that we need to 
look at more in-depth. 


Relative Movement 
When the system goes to read the 
current position of the Power Glove, it 
returns a data structure that includes a 
number of useful fields. Three of the 
fields relate to the location change be- 
tween the last time the Power Glove was 
read and the current read. We can use 
these values to perform a relative move- 
ment of the virtual hand. This is what 
we doif HEAVY is not setto0. A value 
other than O indicates that the virtual 
hand has picked up an object that has 
some value of weight. 

We use the value in the HEAVY 


variable to change the amount of move- 
ment by the virtual hand. This is 
accomplished by dividing the amount 
the Power Glove has changed by the 
value in HEAVY. If we put a large 
number such as 10 in the variable 
HEAVY, we will cause the virtual hand 
to move 1/10 of its intended movement. 
This causes the object and virtual hand 
to move very slowly and gives the effect 
of weight. 


Second Change 

The second change that we must do to 
the original REND386 code occurs in 
the main loop of our control program. 
Figure 3 shows the necessary code 

The code in Figure 3 has two func- 
tions. The first is to attach the object the 
virtual hand is gripping to the virtual 
hand itself. The second function is to 
determine if the object we are picking 
up is an object that we want to have 
weight. As you will see in the code, the 
object we call GREENBALL is the 
object that will exhibit a weight factor 
of 2 since we set the variable HEAVY 
equal to 2. 

When the user drops the object, one 
of the most important things that has to 
happen is the variable HEAVY is set 
equa! to O so that the virtual hand does 
not show any signs of being heavy. 


Demonstration Software 

The demonstration program for adding 
weight to virtual objects is called 
WEIGHT.LZH and can be found on the. 
PCVR Magazine Support BBS at 608- 


abs_move_segment(wrist_seg, p->x, p->y + Y_GLV_OFFSET, p->z + GLOVE DIST); 


else 


rel_move_segment (wrist_seg, p- > dx/weight, p- > dy/weight, p- > dz/weight); 


Figure 2 
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877-1017. The program requires the 
use of a Power Glove connected to the 
parallel port. 

The program is executed by typing 
the word WEIGHT followed by RE- 
TURN at the command prompt. Once 
the necessary files are loaded in, you 
will see a virtual floor with two spheres 
on it. One of the spheres is yellow and 
the other is green. You will also see 
your virtual hand floating in the air. 
The Power Glove controls the move- 
ment of the hand. 

The object of the demonstration pro- 
gram is to first move the virtual hand 
around to get practice using it. Then 
move the hand over to the yellow 
sphere. When the back of the virtual 
hand turns BLUE, you can pick up the 
sphere by making a grip with the Power 
Glove. Make sure that the back of the 
hand stays blue. Once you have done 
this, keep gripping your hand and move 
the virtual hand and object to get a feel 
of normal weight. 

Now release your grip on the yellow 
sphere and move your virtual hand over 
to the green sphere. Grab the green 
sphere like you did the yellow ball and 


move your virtual hand. You should 
not be able to move it much. We have 
added weight to the green sphere. If 
you move back and forward between 
the different spheres, you should find 
yourself automatically limiting your 
arm movements when you go to pick up 
the green sphere. 


Conclusion 

Obviously, adding software weight to 
virtual objects is a problem which can 
easily be overcome but there is a defi- 
nite reaction by our bodies. This simu- 
lation could be taken a step further and 
clearly differentiate the two objects by 
using objects that appear to be light and 
heavy. This would give our brain a 
further cue that we are dealing with 
objects of different weight. 


if ((palm_color == 1) && (gp.gesture = = G_FIST)) 


attached segment = (SEGMENT *)get_object_owner(current_obj); 


attach_segment ( (SEGMENT *)get_object_owner(current_obj), wrist_seg ); 


Feature 


if (!strempi(seg_getname((SEGMENT *)get_object_owner(current_obj)), “GREENBALL”)) HEAVY = 2; 


one_attached = 1; 


update segment ( body_seg ); 


click = 1; redraw = 1; 


} 


if (click == 1) && (gp.gesture = 


= G FLAT)) 


detach_segment (attached_segment); 


click = heavy = 0; 
redraw = 1; 
update segment (body seg); 


Figure 3 
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Luke Hoffman 
Luis Lopez 


he ability to interact with 
computer generated environ- 

ments is essential to virtual 

reality applications. Not only 

should the user be able to 

affect the environment, the environ- 
ment should be able to affect the user. 
Weare going to present here some of 
our experiments with coupling the 
Logitech Space Mouse and the 
MondoTronics Tactor feedback device. 
The Logitech Space Mouse is an 
acoustic tracking device. It uses three 
acoustic transducers mounted on a tri- 


Mouse Tactors 


The MondoTronics Tactor is a tactile 
feedback device thatuses a titanium and 
nickle alloy wire or “muscle” wire to 
create a tactile feedback sensation. 

The muscle wire has a unique prop- 
erty; when it is stretched, a current 
running through the wire will cause the 
wire to try to return to its original 
length. The force generated by this 
process can be used in a number of 
ways, for example creating tactile feed- 
back. 

The Tactor is connected to a PC 
through an RS232 port and an interface 


...our experiments with coupling the Logitech Space Mouse and 
the MondoTronics Tactor feedback device. 


angle attached to the mouse and three 
acoustic receivers on a separate tri- 
angle. Both the mouse and the receiv- 
ing triangle are plugged into a control 
box which is linked to the computer 
using an RS-232 interface. 

The mouse has the normal three but- 
tons plus an additional button mounted 
on theside. Logitech’s intent in adding 
the side button was to allow the user the 
option of moving the mouse around 
without changing the mouse’s position 
reflected in the virtual world. 


box provided by MondoTronics. 


Interfacing the Logitech 


Space Mouse 

The Space mouse is capable of working 
in two different tracking modes. It has 
one mode for head tracking and another 
for normal mouse tracking. Mouse 
mode is the default mode. It tracks the 
mouse inside a 2 foot cube with an 
accuracy of 200 dots per inch. In this 
mode the mouse can respond with a 
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*R Software reset 


*D Enter demand reporting mode 


*d Demand a report 


*[ Enter incremental tracking mode 
*§ Enter stream reporting mode 
*°E Perform diagnostic tests 


*G Enter Euler mode 


*Q Enter quaternion mode 
*H Enter head tracking mode 
*h Enter mouse mode 


Table 1 
Mouse Commands 


maximum of SO position reports per 
second. 

The head tracking mode is designed 
to track inside a seven foot cube with a 
reduced resolution of 50 dots per inch. 
In this mode the mouse can respond 
with a maximum of 25 reports per 
second. The rotational resolution is 0.1 
degrees in mouse mode and0.5 degrees 
in head tracking mode. 

The mouse has three different report- 
ing modes: stream, incremental, and 
demand. In demand reporting the com- 
puter asks the mouse for a report each 
time the application needs to know the 
mouse’s position. In stream reporting 
the mouse sends reports back continu- 
ously. Incremental reporting is similar 
to stream reporting, except the mouse 
sends reports back only while it is 
moving. Table | shows the commands 
for controlling the mouse. 

The mouse has two formats for re- 
turning data to the computer, Euler and 
Quaternion. In Euler mode the mouse 
returns the status of the buttons, the x, 
y, and z location, and the roll, pitch, 
and yaw of the mouse in a 16 byte 
record. In Quaternion mode the mouse 
returns the status of the buttons, x, y, 
and z location, quaternion twist, and 
quaternionx, y, andz. Inthisarticle we 
will be using the Euler mode for our 
data. Table 2 shows the format of the 
data the mouse returns to the computer 





in Euler mode. 

The first byte of data returned in 
either mode is a set of status bits. This 
byte has bits set when the side, left, 
middle, and right buttons are pressed. 
There are two other status bits relating 
to the mouse’s position. The first is the 
fringe area bit. This bit is set when the 
mouse is almost out of range. The other 
bit is set when the mouseis out of range. 
The first bit in the status byte is always 


Feature 


one. This can be useful for finding the 
first byte of a record; since in all the 
other data bytes returned by the mouse, 
the first bit is 0. 

The x, y, and z location data is 
returned in three byte groups. Each of 
these bytes contains seven bits of data to 
form a 21 bit signed integer value. 
Each bit of the location data represents 
approximately 1/1000 of an inch in the 
real world. Of course the scales in 
virtual world will vary. 

The roll, pitch, and yaw data is 
returned in two byte groups. Again, 
each of these bytes contains seven bits 
of data to form a 14 bit signed integer 
value. Each bit of the location data 
represents 1/40 of adegree. Our Space 
Mouse has a peculiarity; as any of the 
angles rotate through zero there is a data 
jump. We have found that we have to 
test for a negative angle and add an 
offset to the data. 


Interfacing the 


Mondotronics Tactor 
The MondoTronics Tactor is almost 


Byte Data 


Byte 1 
Byte 2 
Byte 3 
Byte 4 
Byte 5 
Byte 6 
Byte 7 
Byte 8 
Byte 9 
Byte 10 
Byte 11 
Byte 12 
Byte 13 
Byte 14 
Byte 15 
Byte 16 


INNNK KKK XK 


Status Data 


Bits 20 - 14 
Bits 13 - 7 
Bits 6-0 
Bits 20 - 14 
Bits 13 - 7 
Bits 6-0 
Bits 20 - 14 
Bits 13 - 7 
Bits 6-0 
Bits 13 - 7 
Bits 6-0 
Bits 13 - 7 
Bits 6-0 
Bits 13 - 7 
Bits 6-0 


Euler Mode Data Format 
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trivial to interface to the PC. All that is 
required to make the Tactor provide 
feedback to the user is writing a byte out 
the PC’s serial port. It just doesn’t get 
much easier than that. The Tactor can 
respond to outputs as fast as twice a 
second. 


Coupling the Two 


Devices 

We have coupled our Space Mouse and 
Tactor together by using velcro tape to 
attach the Tactor's control box to the 
bottom of the mouse and the Tactor to 
the left mouse button. This allows us to 
provide the user a feedback when the 
mouse is’ in certain areas or is able to 
pick up objects in the virtual world. 


DOS Driver 


We have included a DOS program to 
test the Space Mouse and the Tactor. 
The program consists of three files 
test.c,. mouse6d.c, and ibmcom.c. 
Test.c is the main program to test the 
position of the mouse and pulse the 
Tactor when the mouse goes into a 
fringe area. Mouse6d.c is a set of 
routines to use the mouse and the Tactor. 
Ibmcom.cis the same ibmcom.cseen in 
earlier issues of PCVR. 


Windows Driver 
The Windows 3.1 version will require 


os) 


r. 
6 
5 
4 
3 
2 
l 
0 


Meaning 


Always Set 


Set when mouse is in Fringe Area 


Set when mouse is out of range 
Not used 

Set when side button pressed 
Set when left button pressed 
Set when middle button pressed 
Set when right button pressed 


Table 3 
Status Data Byte 





a message-based approach — as with 
any good windows program. We have 
includedaC+ + class, called Logitech, 
that provides multiple Logitech 6DOF 
mouse support under Windows 3.1. 
Some interesting problems arise in this 
environment and I don’t claim that the 
code here is the optimal solution — I do 
happen to know its a good solution. 

The main messages to be aware of are 
the WM_COMMNOTIFY and your 
own user defined message that you’ll 
give the Logitech object when request- 
ing data. 

With the Logitech object you really 
don’t have much to do with the 
WM_COMMNOTIFY message. The 
object must process this message inter- 
nally using its own special 
ProcessCommNotify() function. 

When you need mouse data you use 
the object’s Request6DOF() function 
to tell the driver you’d like mouse data. 
The driver will let you know when it's 
ready by sending outa message that you. 
specified in the Request6DOF() argu- 
ments. 

To use this class with multiple mice 
(mouses?) you'll create as many objects 
as you have ports with Logitech devices 
and separate the WM_COMMNOTIFY 
messages via the wParam argument. 
This should be crystal clear to Windows 
programmers and obvious in the source 
code comments and object calls. 


Feature 


Conclusion 

The Logitech Space Mouse and 
MondoTronics Tactor make an excel- 
lent low cost alternative to a data glove. 
The combination provides the capabil- 
ity of 6 degree of freedom input and 
tactile feedback. The use of C++ in 
the Windows version is a natural, easy 
way to provide mulitple mouse support 
and device encapsulation. 


Software 
The software mentioned in this article is 


available on the PCVR Magazine Sup- 
port BBS at 608-877-1017. 
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Feature 


Thermal Feedback 


CM Research 


new concept has been de- 

veloped that allows tem- 

perature to be part of the 

Virtual World. The Dis- 
placed Temperature Sensing System 
(DTSS) can “display” temperature in a 
virtual reality system. The DTSS can 
also serve as a feedback device for 
telerobotics. 

For Virtual Reality applications the 
virtual world software would be re- 
quired to have a temperature map of its 
world. By whatever means ( magnetic 
tracker, ultrasound tracker, etc. ) the 


reality and telerobotics an electronic 
temperature sensor is uséd to gather 
remote temperature data. The output 
from the sensor is fed to a computer 
control network that drives a small 
thermoelectric heat pump. The ther- 
moelectric heat pump is placed in con- 
tact with the human body. A feedback 
sensor, integral with the thermoelectric 
heat pump, transmits the temperature 
feedback to the control computer, which 
allows proper regulation of the tem- 
perature on the sensing area of the 
body. 


The Displaced Temperature Sensing System (DTSS) can eee “4 
temperature in a virtual reality system 


CM Research is a 
Instrumentation and Control 
Development Company. CM 

develops VR systems as well as 
VR devices. They have been in 
business for 5 years. 


hand and fingers, which have been 
instrumented with thermodes, would 
be tracked. The temperature associated 
with the current position would be 
transmitted to the DTSS via a serial data 
link (RS-232). The DTSS would pro- 
vide that temperature to the fingers. 

For Telerobotic operation the func- 
tion of the DTSS is to transmit a tem- 
perature from a remote location to the 
fingers where the temperature can be 
felt. 

The concept is simple; in both virtual 


Presenting Temperature 


Information 

Information has two basic types: inher- 
ent and abstract. Inherent information 
is information that is common to all 
humans. For example hot, cold, loud, 
rough, smooth are common to all hu- 
mans, regardless of how the idea may 
be expressed. Abstract information is 
text, graphics, and other things that 
require interpretation and prior knowl- 
edge. 
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Heat Flow 





The notion of temperature is implied 
in our language that describes reality: a 


summer day, a winter storm, a cup of 


coffee, or a drink at the water fountain. 
Thermal sensation gives other cues to 
the nature of things in the environment 
around us; for example, the average 
person can easily tell the difference 
between metal and wood because the 
difference in the thermal conductivity 
is felt as apparent cold. Temperature is 
inherent information and therefore best 
displayed as hot and cold - i.e. felt as 
hot and cold. Reality is not complete 
without temperature. It fills in our 
picture of reality with the details that 
make everything seem correct. 

The DTSS allows use of physiology 
deception to enhance realism of the 
virtual world. In addition to presenting 
thermal information Weber’s Decep- 
tion can be used to create the sensation 
of touching an object. Weber’s decep- 
tion is the sensation of pressure or 





| Hot Junction Junction 


Area To Be Cooled 


Cold | Cold tunetion =| 


© 


Figure 1 


contact caused by slightly cooling the 
skin. [6] 


Thermoelectric 


Heat Pumps 

A thermoelectric..heat pump (some- 
times called a Peltier Device or a ther- 
moelectric cooler) is a solid state device 
that moves heat from its cold side to its 
hot side. Thermoelectric heat pumps 
are heat pumps just like the mechanical 
heat pumps used in refrigeration or air 
conditioning except they have no mov- 
ing parts. All of the thermodynamics 
laws that govern conventional heat 
pumps also govern thermoelectric heat 
pumps. 

A thermoelectric heat pump can be 
thought of as a thermocouple being 
driven backwards. A thermocouple is 
a common temperature measurement 


-device consisting of a junction of 2 


dissimilar metals. When the junction is 


| Hot Junction Junction 











Metal 
Electrodes 







heated an electric current is produced. 
In a thermoelectric heat pump there are 
2 junctions (see Figure 1). One junc- 
tion is located in or on the space to be 
cooled; the other junction is located on 
the heat sink. When voltage is applied, 
the temperature of the junction in the 
space to be cooled will decrease and the 
temperature of the other junction will 
increase and heat will be transferred 
from one side to the other. The thermo- 
electric process is reversible. 

If the current through the heat pump 
is reversed the cold side becomes the 
hot side and heat flows in the opposite 
direction. 

A typical thermoelectric heat pump 
can generate up to a 67 degree Celsius 
temperature difference from oneside of 
the heat pump to the other (the 67 
degree Celsius temperature difference 
is fora no load condition) Heat pumped 
is roughly proportional to the current 
through the heat pump (This is not 
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strictly true; the thermoelectric heat 
pumps are not linear, but do have 
regions where they are near linear. 
There is also a performance difference 
between heating and cooling) Several 
companies make thermoelectric heat 
pumps and are listed in the More Infor- 
mation section of this article. 


Thermodes 
A thermode is an assembly consisting 
of a thermoelectric heat pump, a tem- 
perature sensor, and a heat sink. The 
heat pump moves heat into or out of the 
heat sink to produce a temperature at 
the surface of the thermode. Using 
feedback from the sensor, the DTSS 
regulates the temperature of the surface 
of the thermode. A thermode can also 
serve as an input, sensing temperature 
and surface thermal conductivity. 
The basic physical configuration of a 
thermode is shown in Figure 2. A 
temperature sensor is mounted on top 
of the thermoelectric heat pump. The 
temperature sensor provides feedback 
to the control network. The heat sink is 
in contact with ambient temperature 


Figure 2 





air. 


Safety 


Thermoelectric heat pumps in contact 
with human skin can cause burns. Any 
experimentation with thermoelectric 
heat pumps should provide a way of 
preventing burns. 

The comfort zone for humans is from 
13 degrees Celsius to 46 degrees Cel- 
sius, with pain below and above these 
limits. The average human can feel a 
temperature change as little as 0.1 de- 
gree Celsius over the entire body, how- 
ever, at the finger tip a sensitivity of 1 
degree Celsius is typical. Exact num- 
bers vary from person to person. [7] 

A Thermal Electric Heat Pump used 
to stimulate thermal sensation to finger- 
tips has several inherent safety prob- 
lems: The finger contains heat which 
must be dissipated in order for a person 
to feel cool. Because heat is convected 
to air (through the heat sink) slower 
than heat conducted from the finger, 
the heat sink size for the thermoelectric 
heat pump has to be large enough and 
have enough surface area so that the 


heat sink is not overwhelmed. If the 
heat sink is overcome (usually because 
the heat pump was operated in cooling 
mode for an extended period of time), 
the heat pump can not maintain the 
temperature difference. The heat in the 
heat sink will come back through the 
heat pump and burn the finger. 

Another potential safety problem oc- 
curs if the heat pump is operated in a 
cooling mode for an extended period of 
time and the power to the unit fails. In 
such a situation the unpowered heat 
pump becomes a sandwich of ceramic 
and metal (with good heat conductiv- 
ity), and once again, the heat in the heat 
sink flows back through the heat pump 
and burns the finger. 


Control System 
Figure 3 shows a block diagram of the 
control system used for the DTSS. The 
goal of the control system is to have the 
temperature at the finger tip follow the 
temperature command. 

An early DTSS prototype used a 
proportional control low. It was found 
that in order to have an effective re- 
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sponse time the gain had to be very 
high, but this caused temperature ring- 
ing at the fingertip (a very weird physi- 
cal sensation). The DTSS uses a Pro- 
portional Integral Derivative (PID) 
control law for closed loop control of 
thermode temperature. A PID control 
law allows gross temperature error, 
cumulative error and oscillation to all 
be controlled. Thecontrol law is imple- 
mented in the software. 


Features 

CM Research’s first DTSS product is 
the model X/10. The X/10 is designed 
as a research unit for those who want to 
add temperature to their work. 


- The X/10 has eight thermode chan- 
nels. Each channel is software pro- 
grammable as an input or an output. 
The inputs can be “mapped” to outputs, 
such that the output temperature tracks 
the input temperature; this is called 
analog track mode. Any input can be 
mapped to any output or a group of 
outputs. 


- The DTSS can be operated from the 
front panel or remotely via an RS-232. 
A front panel is provided so that the unit 
can be used in a stand alone configura- 
tion. The front panel also makes trouble- 
shooting easier in situations where the 
X/10 is part of a larger system. 


- Differential analog inputs are provideo 
so the X./10 can track an analog signal 


Temp Command 
Can be Analog 
or Digital 


from some external device. 


- The gains of each part of the PID 
control law (P, I, and D) are software 
adjustable via the front panel or the 
serial communication port. 


- Demonstration software (with source 
code) is included to provide examples 
for interfacing the X/10 to other sys- 
tems. 


DTSS X/10 


Safety Features 

CM Research has elected to develop an 
intrinsically safe thermode. The tem- 
perature of the heat sink is never al- 
lowed to go beyond 45 degrees Celsius. 
This results in some degraded long term 
performance, but provides a simple 
way to overcome the safety problems 
mentioned above. 


- The DTSS X/10 temperature repro- 
duction range is 10 degrees to 45 de- 
grees Celsius, with an ambient tem- 
perature operating range from 10 de- 
gree to 35 degrees Celsius. By operat- 
ing within the comfort zone for hu- 
mans, the temperature differences are 
kept small, which allows for better use 
of energy. 


- The size of the heat sinks are designed 
for maximum surface area. 


- Power to the thermode has to be 
actively engaged by the computer after 


Thermoelectric 
Heat Pump 


Figure 3 


computer power up. 


- Thermostats on the thermode cut 
power to the thermode if the heat sink 
or the surface of the thermode exceeds 
45 degrees Celsius. 


- Redundant safety software zeros the 
input to the thermode if the operating 
range is exceeded. 


Applications 

In a telerobotics application, tempera- 
ture sensors could be placed in the 
fingers of remote manipulators. Tem- 
perature signals would be sent to the 
DTSS and drive thermodes on the fin- 
gers of the operator. The DTSS X/10 
can accept analog input as well as serial 
digital input. 

A virtual reality application would 
not require a temperature sensor input; 
the DTSS would take serial digital 
commands from the computer control- 
ling simulation. For example, 
thermodes would be placed on the fin- 
gers of the virtual explorer and tem- 
perature values would be assigned to 
objects or locations in the virtual world. 
As the hand moved near these objects, 
commands would be sent via digital 
serial communications to the DTSS to 
change the temperature of the 
thermodes. 


System Status 
The DTSS X/10 development is near- 
ing completion and one unit has been 


aS 


Temp Sensor Located 
Between The Heat 
Pump and Finger 
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sold. CM Research is gathering market 
data to determine if a small scale DTSS 
is feasible. Such a system would con- 
sist of a thermode, safety system, ana- 
log drivers and demonstration soft- 
ware. If you are interested in such a 
system, please contact CM Research. 


Conclusion 

Another building block for the virtual 
world has been developed, thus another 
aspect of reality can be simulated. 


More Information 
CM Research 

2437 Bay Area Blvd, #234 
713-488-3598 
713-488-3599 (fax) 


Makers of Thermoelectric 


heat pumps 
Melcore 

990 Spruce St. 
Trenton, NJ 08648 
(609) 393-4178 


Marlow 

10451 Vista Park Road 
Dallas, TX 75238-1645 - 
(214) 340-4900 


ITI FerroTec 

131 Steadman St. 
Chelmsford, MA 01824 
(508) 452-0212 
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CM Research 
DTSS - Thermal Feedback device 
- Cost: $10,000 


CM Research 

2437 Bay Area Blvd, #234 
Houston, TX 77058 
(713) 488-3598 

(713) 488-3599 Fax 


Mondo-Tronics, Inc. 

Tactors - Direct fingertip signal- 
ing for Virtual Reality and 
Teleoperated Systems -. Cost: 
Demo Package - $178.00 


Muscle Wires - (See What's New 
Section on Page 5) - Cost: Sample 
Kit - $59.95 


Mondo-Tronics, Inc. 

524 San Anselmo Ave, #107-16 
San Anselmo, CA 94960 

(415) 455-9330 

(415) 455-9333 Fax 


EXOS - 

Force ArmMaster - joint torque 
feedback to the human arm - Cost: 
$110,000 





Feedback 
Devices 


Sensing and Force Reflecting Ex- 
oskeleton - Cost: $75,000 


Exos, Inc. 

2A Gill St. 

Woburn, MA 01801 
(617) 933-0022 
(617) 933-0303 Fax 


Virtual Technologies- 
CyberForce - computer-program- 
mable grip-force feedback - Cost: 
$vendor 


Contact: 

Virtual Technologies 
PO Box 5984 
Stanford, CA 94309 
(415) 321-4900 
(415) 321-4912 Fax 


Xtensory Inc. - 
TacTools - A tactile feedback sys- 
tem - Cost: $1500 


Xtensory, Inc. 

140 Sunridge Dr. 

Scotts Valley, CA 95066 
(408) 439-0600 
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Cyberterm - Part 3 


Michael 


Snoswell 


n the last two articles we looked at 

the the evolution of CT from an 

initial idea, through the tortuous 

process of finding and using soft- 
ware tools, through to a final develop- 
ment strategy. This development, hav- 
ing covered so much ground (and time) 
has meant considerable changes in the 
goals and design of CT. 

This final article will look at the 
initial aim and how things have changed 
as constraints were imposed and new 
directions found. Feedback from ad- 
vice and experience of others develop- 


CT has been variously described as a 
BBS, a multi-user flight simulator, a 
VR environment, an operating system, 
a cyberspace engine, a game, an appli- 
cation, a network, a communications 
protocol or a MUD (multi-user dun- 
geon). 

Any and all of these apply to some 
degree. Further comparisons can be 
made to Habitat (the cyberspace system 
developed partly by Lucasfilm), the 
Metaverse (from Snow Crash by Neal 
Stephenson) or William Gibson’s 
Cyberspace in Neuromancer etc. 


This final article will look at the initial aim and how things have 
changed as constraints were imposed and new directions found 


Michael Snoswell studied 
science at Adelaide University. 
He lives in Adelaide, South 
Australia with his wife, baby, 


dog, and cat. 


ing similar systems and finally our own 
experiences have shaped CT in many 
important ways. We’ll look briefly at 
those changes and then examine the 
current state of the system and where 
it’s going. 


2. Back To Basics - What 


is Cyberterm? 

Over the last few years this question has 
arisen many times and the answer has 
never been quite the same. 


CT is all of these, with one significant 
difference (except for MUDs), in that 
the world and all the objects within it are 
completely programmable by the end- 
user (see later for constraints on this all- 
encompassing authority). 

CT is a programming platform or 
environment that is 3D, realtime, multi- 
user and fully extensible. Within this 
environment one may play games, run 
applications, send and receive mail, up- 
and down load files, chat with other 
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users, create objects, manipulate files 
and data and shape the environment 
itself dynamically in a complex, non- 
linear fashion that is generally unpre- 
dictable, based upon user's actions and 
the immediate region. 

All of these features exist in the 
current system and are fully mutable 
between functions and to other, new 
functions. 

This may still not be particularly 
clear! Suffice to say that within CT you 
can analyze realtime data, play D&D or 
action games, chat with other users, 
construct new worlds or run a business 
(either a real world business that has an 
interface in CT or a wholly cyberspace 
based business, like contract object 
programming). The cyberspace within 
the Cybernet (a network of Cyberterms) 
is both acommunity of users anda fully 
functional world of its own with agents 
and objects that operate and continue to 
function without human intervention. 
In this way CT is a powerful simulation 
medium. 

CT is therfore a true terminal (win- 
dow) into a cyberspace that is con- 
stantly evolving in complexity and di- 
versity through the interaction of its 
constituent objects and the users who 
use the terminals. 


3. Design Changes 

A lot of initial concepts and ideas have 
changed since the project started early 
in 1992. Some of these changes have 
been painful, others a panacea for well- 
ing frustrations. Briefly here are some 
of the major changes made. 


3.1 Incorrect and Impractical 
Design Concepts 

Some ideas were simply wrong. There 
is no “can’t” to a programmer as such, 
but some ideas were ridiculously 
unfeasible! A fast Zbuffered display 
that used surface textures is a great 
idea, but the technology to achieve this 
for the average user simply isn’t ready. 


The concept of multiple aspects for 
objects, whereby users of computers of 
differing power could smoothly inter- 
act by selecting their required display 
mode and detail is, whilst a good idea, 
quite impractical. 

Multiple computer platforms and op- 
erating systems also turned out to be 
impractical. Not that such develop- 
ments are ruled out for the future, but 
development time has been more pru- 
dently spent in getting the system up 
and running in the first place (which is 
better than having a non-working sys- 
tem on multiple platforms!) 


3.2 Learned Design Changes 
Some ideas for CT, especially for user 
interface and object control could not 
be tested until the system was up and 
running. Some methods of locomotion 
turned out to be impractical, unrealistic 
or inconsistent. The whole issue of 
whether to enforce “real world” limita- 
tions like gravity, collision detection, 
fundamental physical laws like fric- 
tion, evolution overtime etc. , all needed 
to be carefully considered but ulti- 
mately could only be decided upon after 
“trying it out” upon users to measure 
their response. 

Lessons that others had learned in 
similar environments (Habitat, from 
“Cyberspace - the next step”, by 
Benedikt) taught a great deal about 
environmental design, universal con- 
sistency, community structure (roads 
etc.) and object functionality which 
could only be learned from having a 
functioning system with a large number 
of users. 


4. The Demo Version 

CT has reached a point where a demo 
version can be released. At the time of 
writing, the release is being prepared 
and should be available as you read this. 
One might have thought of the demo 
milestone as being a temporary plateau 
in development. On the contrary, once 





the system achieved functionality the 
development and evolution of the sys- 
tem has increased dramatically. The 
step from prototype to multi-user sys- 
tem has vastly increased the complexity 
of the system, simply by nature of the 
users’ interactions with the environ- 
ment and their creation of events and 
objects. 


4.1 Enforced Constraints 
Due toa number of hard learned lessons 
from other system developers, we have 
chosen to impose a number of con- 
straints upon users within the system. 
Most notably, these refer to the altering 
of object creation files and controlling 
objects in the remote servers. Users can 
“hack” away at their system at home to 
do whatever they want (see later) but 
the public sectors controlled by the big 
(multiline) servers will have curtailed 
programmability, mainly due to secu- 
rity considerations. 

A number of functions have been 
removed from the programming lan- 
guage, (Tcl), to prevent illegal use of 
system resources and limits have been 
placed upon the number of objects 
users can Own within those controlled 
sectors. 

This is a precautionary temporary 
measure until user’s behaviour has been 
monitored. A number of horror stories 
from fellow system developers has urged 
this measure and | (and other CT sysops) 
have no wish to learn these lessons 
directly. 

Permissions, based loosely upon the 
unix “user, group, world” “read, write, 
execute” scheme have been adopted to 
enhance security but it remains to be 
seen whether this is too strict or too 
inflexible. 


4.2 User Interface 

Through experience and advice, the 
user interface has “devolved” to be 
very simple. A minimum of keys on the 
keyboard can control direction and 
motion, but this is more intuitively 
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done using the arrow keys or the mouse. 
The AUIBs (Agent User Interface But- 
tons) are fully implemented and pro- 
vide key input messages to the system, 
these are programmed on the fly by 
agents and appear and disappear as 
users enter different parts of the sys- 
tem, depending on what functionality 
they may perform at any one time in any 
given region. 

All keyboard keys may also be re- 
programmed by agents to send mes- 
sages to any (other) agents. 

One significant addition to mail and 
chatting is the use of FEDs (facial 
expression displays). These consist ofa 
series of facial expressions mapped to 
the function keys. When typing mail, 
the facial expression is embedded into 
the text. This is a more flexible version 
of the common ASCII faces :-), :-(etc. 

Also, when chatting to other users, 
the expression is used to modify your 
own aspect, so those people you are 
chatting to can see the expression on the 
face of the object that represents you, 
directly. This expression lasts a few 
seconds then returns to a default neutral 
expression. 

This system was developed in con- 
junction with Philippe Van Nedervelde 
of Belgium to enhance on-line chats and 
to provide a “higher bandwidth” of 
communication between users. A dozen 
initial expressions have been designed, 
but work is continuing to determine 
which will be most commonly used. 


4.3 Environment and 
Operating Concepts 

To briefly recap on what was described 
in the earlier articles: 

Each user runs CT on his PC at home 
(or wherever). This program has a 
CLIENT and a SERVER in it. The 
connection to the SERVER is made 
automatically and the user doesn’t even 
need to know about this separation. The 
CLIENT handles all interaction with 
the user as far as movement goes. The 
SERVER controls a region of cyberspace 


called a SECTOR. 

User commands are issued from the 
CLIENT to an AGENT running in the 
SERVER that represents the user. This 
AGENT can understand a few basic 
command like MOVE, TURN, STEP. 
These commands are interpreted by the 
AGENT, then passed on to the SERVER 
which distributes the action to any other 
logged in users or interested parties. 

All objects within the system have 
default behaviour to some basic com- 
mands (ie HIT, PUT, GET, USE, 
MOVE, TURN, STEP etc). For in- 
stance, if no special function has been 
assigned to an object, then in response 
to a HIT message (ie when something 
hits it), it will check to see if it can 
shatter, if the force of the hit is suffi- 
cient to shatter it, if the force is above 
an “adhesion” threshold to see if it 
moves from the object it is sitting on 
and finally sees if any objects it sup- 
ports need to be notified of a change. In 
this way, as an object is hit, it may break 
into many parts, or just move a bit then 
stop, or crack, or move and cause 
objects it supported to move down (like 
in a stack of blocks). 

If specific responses to these com- 
mands or other commandsare required, 
they can be appended to or replace the 
default responses. 

SERVERs themselves are divided 
into two types, public and specific. 
Objects which a user acquired in a 
public server will always work in an- 
other public server. Specific servers 
can only run particular classes of ob- 
jects (outside those which originated 
there). 

For instance, if you go and play a 
high tech adventure game and acquire a 
laser gun, you can take it into a medi- 
eval D&D server game, but it won't 
operate. Any item you acquire goes into 
a bag that you carry. The bag keeps 
track of what it contains. At any one 
stage, the bag only contains references 
to the objects, not the objects them- 
selves, unless you specifically state 


otherwise. 

In this way, if you have an object 
called “multimedia encyclopedia”, the 
data itself doesn’t get transferred 
everytime you transfer between serv- 
ers. Also, some objects you own will 
execute remotely but create a local 
representation for you to use. Other 
objects will actually transfer themselves 
in entirety (like a pet “dog”). 

A basic currency exists throughout 
the Cybernet. This currency (yet to be 
named!) is based upon energy and CPU 
time. In this way, if you want to write 
agents that consume a lot of CPU time, 
then it'll cost more. CPU time on your 
machine at home is of course free, and 
users may even hire out their CPU time 
if they’re not using their computer 
much. Energy cost means that moving 
around quickly uses more energy than 
moving slowly etc. The relationship 
between these factors is not linear and 
we are still working out what is a good 
balance. 

Credit is obtained when users log into 
a public system (a fixed amount per 
day) and in a variety of other manners 
(such as writing and selling agents, or 
selling objects you find). 

Agents effectively run as tasks. For 
instance, when downloading a binary 
file from a server, an agent is created to 
handle this function. It sends the file in 
blocks (default 1k) and upon each itera- 
tion of the agent timing loop, the next 
block is sent. The CLIENT has specific 
code to handle binary files and writes 
the block out to disk. 

Multiple file transfers may be in 
progress at once while the user is still 
able to move about and interact in the 
sector. In the same way, when a user 
first logs into a server, the internal I/O 
buffers can handle only about 300 ob- 
jects at once, so the information regard- 
ing what the world looks like is sent in 
blocks, starting with the objects nearest 
the user. 
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4.4 Object Programming 

As system development continues, the 
functions available to agents is increas- 
ing constantly. There are functions to 
locate the nearest object based upon its 
type, to change an agent’s timer code, 
to move an object and many more 
(about 50 in all so far). Most of these 
functions have multiple parameter sets 
(i.e. are overloaded). 

A number of Tcl commands have 
been removed from the library to pre- 
vent malicious damage to systems. These 
include file reading and writing files 
and execution of system commands. 

The world of the user's machine is 
loaded from the WORLD.USR file 
which contains definitions of objects 
and code for agents. This file can 
include other files (up to about 15 levels 
deep) which may define detailed re- 
gions within the world (such as a forest 
or gamearea). Also, included files may 
beencrypted/compressed to ensure they 
are not modified by users (as may be 
the case in a commercial application). 

All code is implicitly multi-user and 
the programmers need not be con- 
cerned by by multi-user issues but some 
issues of state are important (see be- 
low). 

Figure 1 shows some example code 
from the CT prototype which demon- 
strates a number of features of the 
system. 

I hope this gives some indication of 
the power of the system, especially if 
you take into account that agents can 
modify the code of other agents! (within 
the permission guidelines) 


4.5 Commercialization 

As a “hobby” project, CT would not 
progress very far. To fully develop its 
potential and to spend enough time 
programming it I have decided to “go 
commercial” so that I may sustain 
myself as a developer. For this reason, 
the CT user software is shareware and 
the multi-line server software costs an 
equivalent amount to other multi-line 


BBS software. Sysops may procure 
their own income through providing 
commercial use of the system for busi- 
ness front end interfaces, advertising, 
per-unit-time user charging or yearly 
fees etc. 

Currently CT runs on a multi-line 
system out of Adelaide, Australia and 
negotations are being finalized for fur- 
ther systems in Australia, USA and 
Europe. International multi-line serv- 
ers will be interconnected via Internet 
to provided a global cyberspace called 
Cybernet. Costs will be incurred to 
users who “hop” to international serv- 
ers (or for their agents to do so) but the 
cost for this service is expected to be 
very low to encourage integration and 
diversity between environments. 


5. Future Directions 

The next milestone is the official CT 
release which is being funded from 
investment interest based upon the cur- 
rent demo version. The most notable 
differences will be a switch to the 
Watcom compiler and my own render- 
ing engine that is integral to the object 
database, vastly speeding display frame 
updates (to approximately 10-20 fps). 
By early 1995 15 and 24 bit VGA and 
accelerated cards will be much more 
commonplace and these will be directly 
supported . (The current system uses 
256 colors “folded” down from 24bit 
color). 

Sound is a much needed feature and 
“mood” sounds, suitable for various 
regions will be supported, including 
speech synthesis and recognition (if 
such technology is readily available). 

HMD and “dataglove” availability 
should make it clearer which peripher- 
als are widely used and which will have 
along “product life”. 6D input devices 
are still relatively expensive too. The 
CT design has provision for these and 
other controlling devices but support of 
any particular productat this time would 
be an injudicious use of my limited 
resources. 


Implementation of CT on other plat- 
forms (most notably Sun, Macintosh 
and Amiga) will go ahead if the current 
system is successful on the PC. 

Persistent objects are also a high 
priority. This is currently being devel- 
oped, but has raised some surprisingly 
difficult issues. 

As thecurrent system evolves through 
added technical features and increased 
user interaction, new directions are 
sure to emerge, emphasizing new para- 
digms, functional requirements and 
bottlenecks. Already, the system has 
achieved vast complexity, making it 
difficult to predict the overall direction 
of the system, save to say that it will be 
governed by the users and hopefully not 
by technical constraints. 


6. How To Get It! 


By the time you read this, the CT demo 
should be available via anonymous FTP 
from ftp.adelaide.edu.au and from all 
ftp archive mirror sites. In addition, it 
will be available through the 
Compuserve virtual reality discussion 
forum and anumber of major BBS sites 
throughout USA and Australia. Details 
of the demo and further developmental 
status should be available at 
ftp.adelaide.edu.au or by “finger -1 
snoswell@guest.adelaide.edu.au” or 
you can mail that address directly to 
reach me for further questions. 

The demo comes with the software, 
all ancilliary files and a registration 
form. While this release is a 
demonstation of CT, it is fully func- 
tional and compatible with the official 
release that is scheduled for late ’94. In 
order for users to connect CT to a 
remote multi-line server, they must 
register to receive a Cybernet username 
and password. 

Registered users will also receive full 
printed user and programmer docu- 
mentation tor CT, the complete docu- 
mentation set in archived format 
(approx. 125k compressed), a list of 
the nearest servers they can log onto 
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and will also receive a regular newslet- 
teron CT developments, programming 
tips etc., which is expected to be an 
online forum provided to all registered 
Cybernet users. 

Registration cost is $US30 (VISA/ 
MC, or international postal order) or 
$US35 for cheque, or the equivalent in 
your local currency. Postal orders can 
be sent to Scarce Services, PO Box 96, 
Kensington, SA, 5068, Australia, or 
phone to +44 8 364 2364 or Fax +44 
8 332 3716. 

Unregistered users may log onto re- 
mote multi-line servers in text mode (ie 
with standard comms software) to down- 
load the CT software and other associ- 
ated files and will be able to log on to 
the server with CT for approximately 
20 minutes as a “guest” if they have not 
registered. 


(EDITOR: Once the demonstration 
system is available, we will upload it to 
the PCVR Magazine Support BBS) 


Feature 


— begin shoot.app 
# Multi player shooting game All uppercase identifies in the first column of each row refer to an 
# object name defined in OBJLIB.USR that links directly to a PLG file 


default_scale at 4 

default_translate 200 0 200 

# By default, when an object gets hit, then detsroy itself 
default_message_handler 

if {{get_mailbody] == “HIT"} { destroy self } 

end_code 


# This agent creates 50 randomly placed targets then destroys itself 
DEFPS 
name target_generator 
create_code 
for {set i 1} {$i<=50} {incr i} { 
set posx [expr 200.0+({random]-0.5)*20.0] 
set posy 1.5 
set posz [expr 200.0+([random]-0.5)*30.0] 
set id \ 
[make_object \ 
$posx $posy $posz \ 
0.00.0 0.0\ 
0.0 0.0 0.0 \ 
AGENT Target$i 0 TARGET \ 
0.0 0.0 0.0 \ 
0.025 0.025 0.025] 


destroy self 
end_code 


# This target creates shrapnel pieces (up to 30) that fly off in random 
# directions. The shrapnel self destructs after 0-8 seconds 
DEFPS tx 40 tz 25 
name Test target 
message_handler 
if {[get_mailbody] == “HIT"} { 
set pos [get_pos self] 
set max [random 30] 
for {set i 1} {$i<=$max} {incr i} { 
set velx [expr ([random]-0.5)*5.0] 
set vely [expr ([random]*0.5)*5.0] 
set velz [expr ([random]-0.5)*5.0] 
set id \ 
[make_object \ 
[lindex $pos 0] [lindex $pos 1] [lindex $pos 2] \ 
0.0 0.0 0.0\ 
$velx $vely $velz \ 
AGENT Shrapnel$i 0 SHRAPNEL \ 
0.00.00.0\ 
0.1 0.1 0.1] 
timer_code $id “destroy self” 
timer_interval $id [random 8000] 
} 


destroy self 


} 


end_code 





# agent to set up spacebar and mouse button to fire bullets 





# if the 4th param of the define_... funcs is omitted, then the msg will be 
# sent to the agent making the call 

# 

# the +FIRE! means if a button already exists called that sends the FIRE! 
# msg then reuse it with the word (“Shoot” in this case, which hasn't been 
# defined before) 


Figure 1 - (part 1) 
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# get_id (distance, obj type) 
# distance is any positive real number 

# obj_type is (user, agent, pps, any) 

# a-single param of “self’ may be used to get the agents own id 

# 

# all code assignment funcs (like timer_code) can have a “self” parameter 
# otherwise pass the id of the object to assign the code to 

# 
























DEFAGENT tx.2001 
name define_kbd_agent 
timer_code 
set-.id [lindex [get_id nearest user] 0] 
if {Sid != 0} { 
# also stop user from going underground 
timer_code $id “\ 
set pos \[get_pos $id\]; \ 
if \{\{lindex \$pos 1\] < 0.0\} \\ 
set_pos $id \[lindex \$pos O\} 0.0 \[lindex \$pos 2\] \ 
\ya 






timer_interval $id 500 
define_screen_button $id Shoot +FIRE! Handgun 
define_keypress $id ““ FIRE! Handgun 

destroy self 










end_code 
timer_interval 


A gun you can fire with the space bar or mouse 







































DEFAGENT tx 2000 
name Handgun 


# Make a SPACEBAR keypress send a “FIRE!” message to me 
message_handler 
if {[get_mailbody] == “FIRE!”} { 
set pos [get_pos 13579] 
set vel [get_vel 13579] 
set id \ 
[make_object \ 
[lindex $pos 0] [lindex $pos 4] [lindex $pos 2] \ 
0.00.0 0.0\ 
[expr [lindex $vel 0]*10.0] [expr [lindex $vel 1]*10.0] [expr [lindex $vel 2]*10.0] \ 
AGENT Bullet 0 DEFPS \ 
0.00.00.0\ 
0.1 0.1 0.1] 
# create_code has an optional 3rd argument “dont_execute” that prevents the 
# code from being executed straight away 
create_code $id “set ii 0” 
timer_code $id “\ 
set ii \iner ii\]; \ 
if \\$ii > S\} \\ 
destroy self\ 
\} else \{ \ 
set nid \[get_id nearest pps]; \ 
if \\fexpr \[lindex \$nid 1\]\] < 10.0\} \{\ 
send_mail \[expr \[lindex \$nid O\}\] V’HITV’; \ 
destroy self\ 
\}\ 
\y" 
timer_interval $id 200 






end_code 
— end shoot.app Figure 1 - (part 2) 
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Development | 


Toward Real Stan- 
dards in Virtual Reality 


Bob Pendleton 


he subject of standards al- 

ways causes an emotional re- 

action. Everyone benefits 

from standards. Everyone 
except the people whose plans can be 
directly affected by a change in an 
existing standard or the creation of a 
new standard. 

When I go to a hardware store and 
buy a bolt I know I can go to another 
hardware store and buy a nut that will 
fit that bolt because nuts and bolts come 
in standard sizes. When my modem 
calls your modem they can talk to each 
other because of standards. There are 


are trying to prove you wrong. You can 
always learn a lot from being proven 
wrong. And even more from coming up 
with a workable compromise! 

The first negative response | get is 
“Virtual reality is too new to be stan- 
dardized.” Maybe. But, VR has been 
around fora lot longer than most people 
realize. VR in the form of flight simu- 
lators, tank simulators, tanker simula- 
tors, (you get the picture?) has been 
around since the 1960s. VR has driven 
the development of computer graphics 
hardware and software for 30 years. 
VR seems new because computers that 


Every time I’ve talked about establishing standards for virtual worlds I’ve 
encountered serious negative emotions 


Bob Pendleton has been doing 
product development and 
research in programming 

languages and graphics for 20 

years. He lives just outside 
Austin, Texas. 


even standards that detail the shape and 
the wiring of the little plugs on the wires 
that connect my modem to the phone 
system. There are standards for almost 
everything. 


Standards are a 
good thing 


Every time I’ve talked about establish- 
ing standards for virtual worlds I’ve 
encountered serious negative emotions. 
This is a good thing really. Many 
people do their best thinking when they 


can do some form of VR just gotten 
cheap enough for the rest of us to 
afford. 

In fact SIMNET, the military VR 
network, has been around long enough 
that there is already an IEEE standard 
defining the protocol used by SIMNET 
objects to talk to each other. 

Does the existence of a VR standard 


-have any effect on any other VR stan- 


dards? Only if you want it to. It does 
make sense to go look at SIMNET and 
learn what we can from it. But, stan- 
dards come and go and change over 
time. And, not all standards are appli- 
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cable to all problem areas. What works 
for SIMNET over high speed networks 
of high end machines might not be 
appropriate for personal VR. 

Personal VR is new. Is it too new to 
start developing standards? No. Why 
not? Because the standards that are 
developed early on will help define the 


be publicly reviewed again. This can 
take a very long time. 

So, what do we want to “standardize” 
in personal VR? I'll answer that ques- 
tion with two more. What do we want 
to do with personal VR? And, how 
much machine do you need to run a 
standard conforming VR system? 





So, you decide to just draw wire 
frame outlines of the maze walls. This 
approach will let you keep the frame 
rate up. But, now you can see through 
the walls but I can’t. I don’t think I like 
that. You can see me coming but I can’t 
see you because my machine is drawing 
the walls and yours isn’t. 


It seems to me that using our imaginations is a good way to see 
what a virtual reality system needs to do 
and from that see what needs to be standardized 


scope of the problem. And, they will 
prevent people from duplicating effort. 
But, I fully expect that the first dozen or 
so personal VR standards will wind up 
as historical foot notes. 

The second negative response | al- 
ways get is “ You’ re just trying to make 
me do it your way.” Well yes... There 
are two ways that real standards come 
into existence. One way is market forces. 
The number one seller in a market does 
it (what ever “it” is) one way so every 
one copies the leader. The result is a 
defacto, or so called “industry” stan- 
dard. 

The other way is a lot harder and 
takes much longer.The other way is to 
set up a "standards making" body. 
There are lots of these bodies around. 
Some are well known like ISO or ANSI 
(well known in the US any way.) Oth- 
ers, like the X consortium, are not as 
well known. But, most of them work 
pretty much the same way. 

The usual process for creating a stan- 
dard is to form a committee. The com- 
mittee writes the standard document. 
Anyone who wants to be on the com- 
mittee (or can afford to be on the 
committee) can. be on the committee. 
Once the document is written it is 
usually subjected to public review. Any 
comments raised during the review 
must be looked at by the committee. If 
the public review results in any changes 
in the standard then the standard must 


Hardware 

You have to set. floors. In computing 
there are always machines that can’t run 
some piece of software because they 
don’t have a fast enough CPU, or 
enough memory, or an unusual, but 
required, peripheral device. When you 
design asystem you have to decide what 
class of machine will be needed to run 
it. For example, the original X win- 
dows system was designed with the 
MMM machine in mind. The MMM 
machine has | mip (million instructions 
per second) of. CPU power, a 1 
megapixel display (like a monochrome 
SVGA card) for graphics, and. | mega- 
byte of RAM. 

Why. do you need to set floors? Let’s 
say I build a VR game that takes place 
in a maze. Let’s say that my machine is 
fast enough to draw solid walls in the 
maze and to make sure that things that 
are on the far sides of walls. are never 
visible at 30 frames per second. But 
your machine can’t do all that graphic 
processing. So, you either have to slow 
down the frame rate, or do less work on 
the graphics, right? 

Well, let’s say we are playing the 
game against each other over a network 
or via modem. You slow down the 
frame rate on your machine. This means 
that I can see you before you see me. 
Gives me a real advantage. Ok, you 
have to Keep the frame rate up. 


This brings up another point about 
security in shared virtual realities. Just 
because someone isn’t supposed to be 
able to see you doesn’t mean they can’t 
see you. Virtual walls really aren’t real. 

The nice things about setting floors is 
that in computing they are always parts 
of elevators. The floor just keeps going 
up as the cost of hardware drops and 
performance goes up. 

So, what is the hardware floor for 
today? I don’t know. There are an awful 
lot of 16mhz 386SXs with VGA cards 
in them out there. I wouldn’t consider 
anything less than that as a reasonable 
machine to runon. In fact I have trouble 
considering anything that slow. 


What needs to be 
standardized 


One of my favorite ways to get the 
boundaries of a problem is to do it 
several times by hand and watch what 
gets done. It seems to me that using our 
imaginations is a good way to see what 
a Virtual reality system needs to do and 
from that see what needs to be stan- 
dardized. This way our standard will be 
limited only by our imaginations. 

So, let’s imagine something that a lot 
of us do everyday. I rather enjoy driv- 
ing home from work. I can relax in the 
car, listen to the radio, and think about 
the day. Ido some of my best program- 
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ming driving and in the shower. And, 
I do a lot of writing in the car. 

So, I’m sitting in the car. I can see the 
car, the cars around me, the road, the 
city and countryside that I drive through. 
I guess the most obvious candidate for 
standardization is the visual description 
of worlds and the objects in the world. 

After the visual description of the 
world, perhaps thé most obvious thing 
that needs to be defined is how object 
behaviors atid interactions are described. 
That is, how..d@*yow ‘describe the 
“physics” of virtual-objects? What hap- 
pens when I push on the door? This 
subject is of particular interest to me 
because it seems that half the fun of 
virtual reality is experiencing physics 
that we can’t experience in the real 
universe. ; 

I can also hear the engine of the car, 
the radio, the horns of cars around me, 
and the construction sounds coming 
from the new developments that I pass 
on the way home. Sound is another part 
of the real world that needs to be carried 
over into the virtual world. 

Smell is another sense I should men- 
tion, but since I haven’t a clue how to 
record and playback smells I’m going 
to skip them. 

And then there are touch and texture. 
How something feels is important to 
people and it’s closely tied to both the 
way things look and the way things 
behave. If it looks like a cat; its. fur 
should feel soft, and if it-looks like a 
door we expect it to feel like a door. 

Not only can standards be defined for 
all these aspects of virtual reality. But, 
most of them need to be defined at more 
than one level. 

There is a need for a human readable, 
~ portable, way to describe all these things, 
there is a need for programmer, and 
artist, interfaces that let people use and 
extended the capabilities of a VR sys- 
tem, and there is a need for a concise 
computer friendly form for communi- 
cation between computers. 


What’s an “object” 
anyway? 
At this point I feel the need to say 
something about the word “object.” In 
normal life it means something I can 
see, touch, taste, andsoon. Areal solid 
object. In computer science an object is 
something else again. A computer ob- 
ject is some information and some 
procedures for manipulating that infor- 
mation. 

How in the world did the real world 
word “object” get such a peculiar mean- 


’ ing in the world of the computer scien- 


tist and programmer? 

The answer is that computers have 
been used to simulate the real world for 
along time. The people who developed 
the first really powerful simulation sys- 
tems invented the computer object as a 
way to model real world objects. It 
turned out to be such a valuable idea that 
the concept of an object that was devel- 
oped for computer simulation is now 
found in everything from windowing 
systems to databases. 

As far as I can find out the idea of 
using a computer object to simulate real 
world objects first showed up in the 
SIMULA 67 programming language. 
The details were hashed out and under- 
stood during 1966. 

So, when I say “object” I mean a 
computer object that is most likely 
being used to model a real object. That 
is, a computer object being used for 
what it was invented for. 


Object appearance 
Describing what something looks like 
brings in the whole field of computer 
graphics. The computer graphics field 
is known for its large number of com- 
peting standards. And, for the large 
number of official standards that have 
failed to be accepted and used by pro- 
grammers. 

It is very tempting to adopt one of the 
existing graphics standards. Both 


PHIGS (an official world standard) and 
OpenGL (a rapidly emerging defacto 
standard) offer very powerful graphics 
interfaces. But, they are also very large. 
Adopting one of these as a VR graphics 
standard would load us down with a lot 
of overhead that isn’t needed right now. 
But, these standards developed the way 
they did because people who write 
graphics programs for a living asked 
for all the capabilities in these systems. 
I expect that future VR standards will 
make PHIGS and OpenGL look tiny. 

For something that is supposed to run 
on personal machines the right ap- 
proach is to follow the KISS principle, 
KISS means simply, Keep It Simple, 
Stupid. But, don’t keep it so simple you 
cripple it. And, again you have to set 
floors. 

When we talk about 3D graphics 
systems we talk about the set of “primi- 
tive” operations that are implemented 
by the system. Typical systems imple- 
ment points, lines, and polygons. But, 
they also implement curve drawing 
primitives such as various kinds of B- 
splines and Beziercurves. And they add 
interesting ways of representing sur- 
faces such as triangle strips and meshes. 

Then there are less traditional ap- 
proaches. Why use polygons when the 
real world isn’t made up of polygons? 
Looking at my hands I don’t see.a lot of 
nice clean polygons there. It would be 
nice to be able to use 3D shapes to 
define 3D objects. Why not have a 
system where you describe objects as 
the union and intersection of shapes like 
spheres, cylinders, and cubes? It’s been 
done, it’s done all the time. 

You also have to distinguish between 
the calls you would like to be able to 
make when you are writing a VR pro- 
gram and what kind of information you 
would like to see in a file that describes 
an object that you want to load into your 
VR program. 

What I’m presenting here is a list of 
capabilities that I consider to be a floor 
for graphics capabilities. A full blown 
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standard for VR will grow to include all 
the capabilities found in existing graph- 
ics standards and probably a lot more. 
Let’s concentrate on the external form. 
The description you could create with a 
text editor or have another program 
generate. There are several examples of 
this kind of format out there. If you’ ve 
looked at REND386 you’re familiar 
with the object and world files that it 
uses. 
An object description file is.a set of 
records. Each record can have a name 
so that.it can be referenced by another 
record. A record must: havea type so 
that both people and programs know 
what to expect next. And, sincea record 
might be awfully long, in fact it might 
cross many lines of text, it needs an end 
marker. This kind of record winds up 
looking a lot like a statement in many 
programming languages. 
Adopting “;” as the end marker and 
“:” to mark a name we get records that 
look like: 


NAME.TYPE DATA; 


What are some types of records we'd 
like to define? 


Objects 

First off, we need to know the name of 
the object. So, we need a record that 
states the object's name. And, since 
there could be more than one object 
definition in a file we need a way to 
mark the end of an object. 


name: OBJECT, 
END; 


All ‘the records that define an object 

are stuffed in between NAME; and 

_ END; including other object/end pairs. 

Yes, you should be able to define one 

object inside of the definition of another 
object. 


Range 

After that we need to know the range of 
coordinates that were used to define the 
object. All the coordinates of an object 
might be in the range 0.0 to 1.0, or they 
might be in the range-1.0 to 1.0 or they 
might be in the range 0 to 100,000. It’s 
friendlier to ask than to just say that all 
coordinates are in a certain range. 1am 
going to assume that all axes use the 
same scale. 

We also need to know what the scale 
represents. Is the object measured in 
meters or inches? And how far is it from 
point A to point B? So, the range record 
would look like: 


RANGE 0, 1000, meter, 1, 


Where 0 is the smallest coordinate 
value being used and 1000 is the larg- 
est. The basic unit being used is the 
meter and the distance from 0 to 1000 
is 1 meter. So the basic unit of measure- 
ment for this object is the millimeter. 


Center 

Another interesting question is what do 
We mean when we say that an object is 
at location x,y,z in a virtual world? A 
point can be ata specific x,y,z location. 
An object (usually) occupies a volume, 


“it occupies a lot of points. But, when an 


object is rotated you need to know what 
point to rotate around. So, let’s have a 
“center” record. 


name: CENTER x,y,z; 


I’m using the word “center” because 
I can’t think of a better name for it. 


Color 

Color is another thing that we must be 
able to specify. Everyone has a favorite 
way to specify a color. For me the 
simplest (probably because I’m most 
used to it) is to specify color as a red, 





yvreen, blue, triple. The range of values 
for each of these is a fraction from 0 to 
1. You could use numbers from 0 to any 
thing, but fractions let you specify as 
much precision as you want. Soa color 
record would look like 


COLOR r, g, b; 
So that, 
COLOR 1.0, 0, 0; 
is full intensity red = 
COLOR 0.5, 0.5, 0.5, 
is a medium intensity gray. 


Normals 

Shading and lighting computations as 
well as back-face removal need to know 
which way is up. A normal is a vector 
that points at 90 degrees from a line or 
a plane. 


NORMAL 1.0, 2.0, 3.0; 

The easiest way to give the “up” 
direction isto givea vector that “points” 
in the correct direction. This form 
amounts to just another point, but it is 
a point along the line that points “up.” 

In most of the computer graphics 
literature-and in most computer graph- 
ics packages a normal is required to 
have a length of exactly 1. It seems so 
easy to have the computer scale it when 
you read the normal record that I can’t 
see the point of this restriction. 


Point 
The most basic graphic element is the 
point. A point record looks like: 


POINT x, y, 2: 


Where x, y, and z are numbers in the 
range given by the scale record. 
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In computer graphics points are used 
to describe the end points of lines and 
the vertices of polygons. Free floating 
points are used to create interesting 
visual effects. 


Vertex 

For doing full blown rendering of com- 
plex objects in 3D you need to provide 
a location, a color, and a normal for 
each vertex of a polygon. I'll call this 
full blown point a vertex. 


VERTEX x,y,z nx,ny,nzr,g,b, 


This form of a vertex record has the 
x,y,z of a point, the normal value 
(nx ,ny,nz) of a normal vector, and the 
r,g,b of a color. But, what if we later 
want to add even more information to 
the description of a vertex? Such as 
surface texture? Or, we don’t want to 
specify all the vertex information? Then 
we want a form of vertex record with a 
lot more flexibility than the one I just 
showed. 


name: VERTEX, 
POINT x,y,x; 
NORMAL nx, ny,nz, 
COLOR r,g,b; 
END; 


If we allow everything but the point 
value of a vertex to be inherited from 
global values, or just plain ignored, 
then this form of.a vertex record lets us 
put in just as much information as we 
want. 

Up until now I’ ve allowed everything 
to have a name, but I’ ve never used the 
names. The example vertex could just 
as well have been written as: 


red:COLOR 1,0,0; 
pl= POINTE X,y.z, 
nl: NORMAL nx, ny, nz; 


name: VERTEX, 
red, pl; nl; 


END, 


Anywhere you can use a record you 
can use the name of another record. 
There are other uses for the names. 
More on that later. 


Lines 

Lines are a standard part of computer 
graphics. You don’t encounter very 
many lines in the real world but, they 
have many other uses. For generality 
let’s provide a general line. 


name:LINE; 
COLOR r,g,b,; optional color 
for the line. 
POINT x,y,2; 
POINT x,y,2; 


POINT x,y,z; list of points to 
draw a line through. 
END; 


A line can have as many points in it 
as you want. Also, anywhere you can 
use a point record you can use a vertex 
record or the name of a vertex or a 
point. And, you can toss incolor records 
anywhere you want. The color infor- 
mation in vertices and color records 
change the color of the line as it’s being 
drawn. 


Polygons 

Polygons are another standard part of 
computer graphics. The basic structure 
of a polygon record is the same as that 
of a line record. If you connect the end 
of a line to the start of the line and the 
line has at least 3 points then you get a 


polygon. 


name:POLYGON, — 
COLOR r,g,b,; optional color 
for the polygon 


NORMAL nx,ny,nz,; optional 
polygon normal 

POINT x,y,z; 

POINT x,y,z, 


POINTx,y,z;  listofpolygon 
vertices 
END, 


You would substitute vertex records 
for point records in a polygon defini- 
tion when you need per vertex normals 
for shading computations and when 
you need per vertex color for color 
blending. 

The surface normal is needed so that 
you can adjust the color based on the 
angle between the polygon and lights. 
Surface normals are also used to throw 
out, that is, not draw, polygons if 
you’re looking at the back side of the 
polygon. And, if you want you can 
have a different color for the front of a 
polygon and a different color for the 
back of a polygon and use the normal to 
decide which color to use. 

Some records that you might want to 
add to the polygon record include: 


BACKCOLOR r,g,b; the 
color of the back side 

CLOCKWISE, 

ANTICLOCK WISE, 


The clockwise/anticlockwise flags let 


the rendering system determine the 


normal by knowing that the points that 
describe the polygon are listed in clock- 
wise or anticlockwise order.In modern 
rendering systems you can also draw 
polygons that are transparent, that are 
drawn using a pattern rather than a 
fixed color using a technique called 
texture mapping, and that have 3D 
surface texture using a technique called 
bump mapping. 
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Text and Fonts 

Ever tried to draw a virtual street sign 
or the title page of a book in a system 
that didn’t provide 3D fonts and text? 
Well, I haven’t but I’ve had to imple- 
ment text drawing and I’ ve had to build 
fonts. All in all I’d rather have them 
built in to any system I’m going to use. 
Each character in a font is an individual 
object, usually a polygon. Considering 
the number of characters in a font you 
could define a complete house with the 
effort it would take to create one full 3D 
font. 


name:FONT width, height, 
"name of the font”; 


The font record is used to map the full 
name ofa font into a nice short name for 
use in text commands. It also states the 
width and height of a character. The 
width and height is the size that the 
largest character in the font will take up 
on the screen. 

To make sure that the font you want 
is available everywhere an object might 
be run you either have to standardize on 
a fixed set of font names or you have to 
have a standard font encoding and then 
include the fonts you use in the object 
definition. I expect that both solutions 
will be used. 

Text has a font name, a color, and 
some letters, numbers, and such. Text 
is drawn in a plane. Let’s use the 
coordinates of the lower left hand cor- 
ner of the text to tell us where to draw 
the text. The lower left hand corner is 
the lower left hand corner no matter 
what language we are writing’in. Some 
languages are written from right to left, 
some from left to right, and some from 
top to bottom. That kind of information 
needs to be part of the font. 

Ok, so we tell the text where to draw, 
and the font tells how to draw it, but 
how do we know how to orient the text? 
We can do that by assuming that text is 
always drawn in the XY plane unless it 
is rotated out of that plane. To specify 


the rotation angles we need a record 
type that I haven’t mentioned before: 


name:ROTATE x-angle, 
y-angle, z-angle; 


where the angles are in degrees. A 
rotate record twists what follows it 
around the X, Y, and Z axes. 

To go along with the rotate record we 
need a scale record and a translate 
record. 


name.:SCALE x-scale,y-scale,z-scale; 


The scale factors are how much to 
change the scale of things drawn along 
each of the axes. 


name: TRANSLATE x-offset, 


y-offset, z-offset; 
Translate moves the origin to x,y,z. 


name: TEXT; 
POINT x,y,z, the lower left 
hand corner of the text 
ROTATE 90, 26, 0; 


COLOR r,g,b; Give the text 
a color 

“Something to write”; 

COLOR r,g,b; 

“Something else to write”; 
END; 


Asusual, anywhere!’ ve used a record 
you can use a record name. 

Anyone who has looked at page for- 
matting languages like PostScript knows 
that this is a very simple approach to 
displaying text. Again, I’m trying to set 
a floor, not a ceiling. 

There are many other ways to do text. 
One interesting approach is to use a line 
with normals and color to define where 
the text is to be drawn. In this approach 
you start the text at the first point on the 
line with “up” being the normal from 
the first point and color taken from the 
color of the first point. This approach 
would let you draw text around a ball or 





along the ridge line of local mountain 
range. 


name: TEXT; 
POINT x,y, x; The starting 
point for the text 
NORMAL nx, ny, nz; The 
“up” direction for the 
text 


“Something to write”, 


POINTx,y,z;  Thenext point 
on the line 

NORMAL nx, ny, nz; The 
“up” direction for the 
text 


“Something else to write”, 


POINTx, y,z; The last point 
on the line 
NORMAL nx, ny, nz; The 
“up” direction for the 
text 
END, 


Another approach is to specify a 
rectangle to draw the text in, a font, and 
a text string and then automatically 
scale the text to fill the rectangle and 
draw it inside the rectangle. This way of 
drawing is handy for doing street signs 
and adding text to the sides of objects. 


Lights 
I started this all with the example of 
driving my car. I drive my car at night 
and it has head lights. I drive past street 
lights. There are little lights in the dash 
board. And, during the day | drive 
under a big light called the Sun. Any 
VR system that doesn’t include a way to 
specify lights as part of an object is, 
well, in the dark. ; 
A light source has a color, an inten- 
sity, and a location in the model or the 
world. A light can also be directional, 
for instance a spotlight illuminates a 
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cone in space. A simple light might be 
represented like: 


name: POINTLIGHT; 
POINT x,y,z; where light is 


COLOR r,g,b; the color of 
the light 
INTENSITY i; the intensity 


of the light 
NORMAL nx, ny,nz, the direc 
tion the light is pointed 
ANGLE theta; angle of the 
cone being lit. 
END; 


The normal value and the angle are 
only needed by directional lights. Lights 
like the Sun need to be modeled as being 
infinitely far away so you don’t give the 
Sun’s location, you just give its direc- 
tion. 

Yeah, I sneaked in a couple of more 
record types, “angle” and “intensity,” 
these types are used to provide a value 
needed to describe a light. As with all 
the other record types they tell us what 
the value (or values) that follow are for 
and how to interpret the value. 


name:DISTANTLIGHT, 
COLOR r,g,b; — thecolor of 
the light 
INTENSITY i; the intensity 


of the light 
NORMAL nx,ny,nz,; points 
toward the light 
END, 


Surfaces of revolution 
Describing something like a wine glass, 
atire, or even acone or a sphere using 
polygons is a time consuming process. 
An alternative is to describe the outline 
of the object using a line and then to spin 
the line around an axis. Think of the 
shape a jumping rope outlines as it spins 
around. It’s the same idea. 


name:SURFACEOFREVOLUTION, if 














any name ever needed 

an abbreviation... 
ROTATE xa, ya, za; which 

axis and how many 


degrees 
STEPS how_many; How 
many steps to take 
LINE; A line record 


or the name of one 
END; 
END; 


The rotate record tells which axis to 
rotate the line around and the angle tells 
how many degrees to rotate the line. 
You can use angles less than 360 de- 
grees to describe things like hemi- 
spheres. 

The sweep angle is divided by how 
many steps you want to take to get the 
number of degrees to sweep the line on 
each step. A set of polygons is gener- 
ated by rotating the line by one step and 
then connecting the points at the origi- 
nal location of the line to the points at 
the new location of the line. You keep- 
ing doing that until you’re done. So, 
you see that a surface of revolution is a 
handy way to generate a lot of poly- 
gons. 

The color of the surface can be picked 
up from vertex records in the line or 
you can include a color record in the 
surface record to define the overall 
color of the surface. Taking the color 
from the line would let different parts of 
the surface have different colors. 


Swept surfaces 

A surface of revolution can easily be 
used to describe the bowl of a coffee 
cup, but describing the handle is an- 
other matter. An extension of surfaces 
of rotation are swept surfaces. Draw a 
polygon that describes the cross section 
of the cup handle and a line that de- 
scribes the curve of the coffee cup from 
where it is joined to the bowl at the top 
of the cup to where it rejoins the cup at 
the bottom. 


Now, sweep the polygon along the 
line. If you stop every so often to record 
the locations of the vertices of the 
polygonas it moves along the line it will 
describe a set of polygons that are on the 
surface of the cup handle. This tech- 
nique works just as well for sweeping 
lines as it does for polygons. There are 
a number of details about swept sur- 
faces that I haven’t mentioned. But, a 
swept surface record would look some- 
thing like: 


name:SWEPTSURFACE, 
PATH ... 
SWEEP. ... 
END; 


Where what follows the “path” tag is 
either a line record or the name of a line 
record. And, what follows the “sweep” 
tag is either a polygon record or a line 
record or the name of a polygon or line 
record. 

The colors of a swept surface should 
be handled the same way the colors of 
a surface of revolution are handled. 
There are many other ways of describ- 
ing surfaces. But, again, I’m trying to 
set floors. 


Putting it all together 
Everything we’ ve seen so far describes 
shapes and assigns colors to them. But, 
it doesn’t actually tell how to draw 
anything. You can’t just draw every- 
thing that’s described in an object be- 
cause the parts with names are used in 
the description of other parts. For ex- 
ample: 


square: OBJECT, 
p1:POINT 0,0,0; 
p2:POINT 0, 1,0; 
p3:POINT 1,1,0; 
p4:POINT 1,0,0; 


POLYGON, pl; p2; p3, p4; 
END, 
END, 
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Should we draw the points and the 
polygon? No, what point is there in 
drawing the points and then drawing 
over them with a polygon? We could 
adopt a policy that says you draw any 
record that doesn’t have a name. That 
works pretty well. But, if what you are 
describing is a hand and the hand has 
five fingers and each finger has several 
pieces that can each be moved sepa- 
rately, you’d like give each part a name 
that can be used to reference the differ- 
ent parts. 

This means we need yet another 
record, the “draw” record. 


hand:DRAW; 
palm, 
thumb, 
index-finger; 
middle-finger, 
ring-finger,; 
little-finger; 
END, 

If the name of the draw record matches 
the name of the object, then it is drawn. 
Since any object may have more than 
one representation we need to allow 
more than one draw record. Adding a 
little more syntax, how about: 


hand[1]:DRAW 


END, 


hand[2]:DRAW 


END, 


hand[n]:DRAW 


END, 


You might want to use different rep- 
resentations of an object depending on 
how far away it is from the viewer, 


depending on the age of the object, or 
to do simple animation. 

And last, for this part of the article, 
we need the export 


record. EXPORT 
first-name,; 
second-name; 
next-name, 
last-name; 
END; 


The export record is used to make 
some of the names defined inside the 
object visible outside of the object. This 
is important for animation. 

There are a few issues that have been 
left dangling. Where can you use color, 
scale, rotate, and translate records, and 
how do you interpret them? 

Although I’ ve used upper case for the 
record types it’s not because I think all 
record types should be in upper case. 
It’s just so they’re easy to read. Also, 
there is nothing magic about the syntax 
I’ve used here. There are many other 
perfectly good ways to write these 
records. I could have made it look like 
C++ class definitions or I could have 
made it look like LISP. 


Object behavior 

I can think of only two ways to describe 
how objects behave. You can either 
have behavior rules built into your VR 
system or you can include programs as 
parts of object descriptions. 

Built in rules are rather like the laws 
of physics we deal with everyday in our 
real reality. Built in rules are great for 
describing what happens if I drive my 
virtual car off a virtual cliff. The built 
in rules can force the car to fall or allow 
it to fly across a river gorge and land on 
the other side. Built in rules aren’t very 
good for describing how the car re- 
sponds when J step on the gas or when 
I turn the steering wheel. 

To describe any kind of behavior that 
is unique to an object you need a 


program that describes that behavior. It 
makes sense to include these programs 
as part of the description of the object 
rather than having one file written in 
one language that describes what an 
object looks like and another file in 
another language that describes the 
behavior of an object. 

‘If your VR system is to run for long 
periods of time you are going to want to 
be able to add new object descriptions 
to iton the fly. This means that you need 
a way to add new programs to your 
system on the fly. There are several 
ways to do this. By far the simplest is to 
include a simple programming lan- 
guage as part of the object description 
language. 

Since VR systems are simulators, 
and simulation programs tend to be 
event driven I’d put behavioral pro- 
grams in event records. 


name:EVENT arg!/, arg2, ... argn; 
Some piece of code that 
describes what to do when 
the “name” event happens. 
END, 


There are two basic kinds of events. 
Events that are built in parts of the VR 
system and events that are unique to a 
specific object or group of objects. 
Built in events are things like “clock” 
that tells an object that time is passing 
and “touch” that tells an object that it 
has been touched and what touched it. 

If an object wants to take a special 
action when an event occurs then it uses 
an event record like: 


clock:EVENT second; 
Do something based on the 
time, 


END; 


Whenaclock event happens the names 
listed after “EVENT” are assigned the 
current time and the program that fol- 
lows the event record is run. A wall 
clock object or a wrist watch object 
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would use the clock event to update 
their hands or their displays if they’re 
digital. The sun could use the clock 
event to update its location in the sky. 
A flower object could use the clock 
event to know when to open and when 
to close. 

Another object might use the clock 
events that come every second to gen- 
erate private events for the passing of 
minutes, hours, days, seasons, or years. 
A tree object wants to know about 
seasons so that it can change the color 
of its foliage and even drop its leaves. 
' Objects need to be able to create 
events and send events to themselves, 
some small group of other objects, or to 
all objects that can be affected by them. 
Flower and sundial objects, (anything 
that needs to know where the sun is), 
would be easier to build if the sun sent 
out “sun_moved” events. Without 
something like a “sun_moved” event, 
how would flowers know where the sun 
was? 

The details of a programming lan- 
guage, or even the modifications needed 
; to make an existing programming lan- 
t 


guage useful for describing object be- 
havior is much more than I can put in 
: this article. All I can say is that such a 
language should follow the KISS prin- 
ciple and try to avoid adding features 
just to add features. 


Summary 

A full blown personal VR standard will 
wind up being a very thick document 
that will include rules for describing 
everything that we can describe about 
the way an object affects our senses and 
how it behaves. Such a standard will be 
limited only by our imaginations. It is 
most important to make sure that a VR 
standard does not limit our imagina- 
tion. 


a 
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VGA-TO-NTSC 
Conversion 


Joe Gradecki 


ost, if not all, visual de- 
vices such as a head 
mounted display require 
an NTSC signal for 
video. The NTSC signal is a standard 
format for video in North America. All 
of the information for video such as 
color and frequency are combined into 
a single composite signal. 

When we use our PC, we commonly 
refer to the signal as VGA or SuperVGA. 
In fact, the real signal consists of a red 
analog, greenanalog, blueanalog, hori- 
zontal, and vertical signals. The moni- 
tor is able to take these different com- 





Converters 
There are many different converters on 
the market. One such model is called 
the PC-VIDEO converter from Boffin 
Limited: (612-894-0595). This con- 
verter sells for a total of $99.00. This 
converter is specific to DOS applica- 
tions. Boffin also sells converters that 
can be used with Windows. You will 
need one of these when executing 
WorldToolKit for Windows. 

These inexpensive converters include 
a 15pin VGA Y adapter. Oneend of the 
adapter attaches to the VGA card in 
your PC, one end attaches to the con- 


In order for us to get the image the PC produces to a head mounted 
display, a conversion has to take place. The conversion is 
performed by a VGA-to-NTSC converter 


Joe Gradecki is publisher of 
PCVR Magazine and has 
dedicated himself to the 
development of PC-Based 
Virtual Reality. 


ponents and produce the image we see 
on the screen. 

In order for us to get the image the PC 
produces to a head mounted display, a 
conversion has to take place. The 
conversion is performed by a VGA-to- 
NTSC converter. The purpose of this 
articleis to show the difference between 
certain converters and specific changes 
that have to be made to some software 
packages. 


verter, and the remaining end attaches 
to the monitor. The converter has an 
RCA jack which outputs the NTSC 
signal we need. A Terminate-and-Stay 
Resident software package is used to 
activate the converter. 

This software package makes spe- 
cific changes to the VGA card in your 
PC. These change the frequencies of 
the output signal. The converter takes 
the signals from the VGA card and 
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molds them into a composite NTSC 
signal. The work involved in produc- 
ing the signal is shared between soft- 
ware and hardware. 

One problem with this type of con- 
verter is it can be incompatible with 
some rendering software packages. 
One such package is VREAM. Once 
the converter software has been acti- 
vated, it has made some changes to 


registers inthe VGA card. The VREAM” 


software executes and makes further 
changes tothe card. The outcome is not 
the NTSC signal we had hoped for. 
Another problem with the inexpen- 
sive converters is the VGA card itself. 
Some of the converters are unable to 
handle the new chipsets that are intro- 
duced just about everyday. I currently 


use an STB S3-based local bus acceler- ' 


ated video card. All of the inexpensive 
converters, $99-$300, were unable to 
convert my VGA signal to an NTSC 
signal successfully. 

When this conversion problem oc- 
curs, we have to step up to a more 
expensive external converter. 


TV-LINK 

One such converter is called TV-LINK 
and is manufactured by KDI Precision 
Products, Inc. This converter retails 


for $1069.00 but can be currently pur- 


chased from KDI for $495.00. 

The unit is about the size of a normal 
3-ring binder. It is very simple to 
hookup. A supplied cable runs from 
the output of your VGA card into the 
unit. Your monitor is attached to a 
VGA OUT connector on the back of the 
converter. After the connections are 
made, asmall software TSR is executed 
that turns on the converter and sets up 


- the signal transfer from the computer to 


the converter. . You are now able to 
connect any NTSC display to the NTSC 
signal output on the converter. In 
addition to the standard RCA output, 


- there are connectors for RGB, S-Video, 


and RF modulated video. 
Just in case you need to control the 


output of the image, there are numerous 
controls for setting the horizontal and 
vertical position, colorlock, over/un- 


-der scan, flicker, and.termination con- 


trol. 

The converter handles any resolution 
up to 640 x 480 with as many as 16 
million colors. 

The small TSR software program 
that initializes the converter is nothing 
like the TSR programs for the other 
inexpensive converters. The TV-LINK 
product handles all of the signal con- 
version in hardware, therefore the con- 
verter can be used with basically all 
software packages and video cards. 

Now for the real test, I hooked up the 
converter to my video card and monitor 
and executed the small TSR program. I 
next hooked up the VictorMaxx 
Stuntmaster using an interface cable 
and fed the NTSC signal from the 
converter to the Stuntmaster. I wanted 
to test the converter using REND386 so 
I chose to execute my park world which 
has a good amount of color in it. I put 
the unit on my head and opened my 
eyes. 

There was a wonderful array of col- 
ors. The blues were blue and the greens 
were green. I continued to move around 
in the world and was very pleased with 
the results. There was no flickering - 
just a perfect.image. 

If you are interested in Virtual Real- 
ity or just need to show Doom on a big 
screen TV, then I would haveto strongly 
recommend this converter. Even at 
$500.00, this converter will save you a 
great deal of headaches that can occur 
from trying to use the inexpensive 
ones. 

Just ask my book editor. He wanted 
to use a converter to show some soft- 
ware at a sales conference. He tried 
three different computers trying to find 
one that would successfully convert a 
REND386 program. He was unable to 
find one. This converter would have 
saved him over a day's work. 





Software 

If you are using REND386 and cannot 
spend $500-$1000 on a converter box, 
you will probably opt for the $99.00 
Boffin converter. This is a good con- 
verter for use with REND386 except 
when you use it with the video drivers 
supplied with REND, you get a very 
nice black box in the middle of the 
image. 

Thankfully, a solution was found to 
this problem and released to the public 
domain. The new video driver is called 
vd256y.rvd and is supplied on the en- 
closed disk. Use this driver in place of 
the normal REND driver called 
VD256.RVD. Follow these steps: 


rename VD256.RVD to VD256.SAV 
rename VD256Y.RVD to VD256.RVD 


You will now have a complete NTSC 
signal from any of your REND386 
worlds. 


Sources 

Boffin Limited 

2500 West County Road 42, #5 
Burnsville, Minnesota 55337 
612-894-0595 


KDI Precision Products, Inc. 
3975 McMann Road 
Cincinnati, OH 45245 
800-377-3334 
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Net News 


R-3386 


he past year or so has seen 

the interest in the REND386 

software package escalate. It 

is for this reason that I present 

you with a reprint of a "press release" 

that was posted onthe sci. virtual-worlds 

USENET group located on the 

INTERNET as well as in the 

CYBERFORUM forum on 

Compuserve. This release details the 

development of a new renderer called 
VR-386. 

The following information was posted 

by Dave Stampe and is reprinted here as 


Virtual 


Reality | 
Application 
Development j 


of any VR software in its class, exceed- 
ing 20,000 polygons per second. VR- 
386 is being developed by Dave Stampe, 
and is an ongoing project which hope- 
fully will bring in other programmers 
to contribute small sections of the func- 
tionality (see the programmer’s notes 
later). 

VR-386 is descended from 
REND386, which was developed by 
Dave Stampe and Bernie Roehl, which 
is documented in the book “Virtual 
Reality Creations” , published by Waite 
Group Press. VR-386 supports most of 


VR-386 i is a freeware VR program for the IBM PC (386 and 
higher) compatibles 


PCVR magazine presents 
NEWS that has been posted on 
the electronic superhighway. 


a service to the PCVR Magazine read- 
ers. 
The message begins 


What Is VR-386? 
VR-386 is a freeware VR program for 
the IBM PC (386 and higher) com- 
patibles. It supports many VR devices, 
including stereo flicker glasses, HMDs, 
the Nintendo PowerGlove, joysticks, 
and so on. 

VR-386 has the fastest drawing speed 


‘the features in the VRC release (version 


5), and adds new features. 


New Features 
Some of the new features of VR-386 
include its better timebase for timing 
and control, its better internal organiza- 
tion for future upgrades, and its simpli- 
fied programmer interface. 

Perhaps most important VR-386 sup- 
ports EMM386 for up to 4 megabytes 
of memory for object storage. This 
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compensates for the large memory use 
of VR-386 caused by its extensive use 
of caching to increase rendering 
speeds.Many future enhancements are 
planned, as listed below. Most impor- 
tant, VR-386 represents a new begin- 
ning and new commitment to program- 
mers after the problems of REND386. 


Internal Rewrites 

Where VR-386 differs from REND386 
is in its internals. While REND386 
explored new ideas in VR and devel- 
oped techiques for high-speed software 
implementation of graphics and inter- 
faces for VR, it was very difficult to 
program with. Full source code 
availabililty wasn’t enough. 

VR-386 begins the process of reorga- 
nizing and cleaning up the code to make 
it accessible to programmers. About 
90% of the old code has been rewritten 
by Dave Stampe, who developed most 
of the original algorithms for REND386. 

This rewrite is aimed at cleaning up 
many of the programming style prob- 
lems with the original code. By remov- 
ing much of the inline assembler, the 
dependence on Borland C will be less- 
ened. 

". By using special API data types (dis- 


cussed later) it should be easier to use 
-libraries in many C compilers and to 


eventually port the code to 32-bit com- 
pilers such as Watcom C32. 

Internally, the super-fast integer/ 
fixed-point math routines have been 
expanded and split off into a separate 
library. This unit is completely stand- 
alone, so may be used in other projects. 
The renderer code has been completely 
rewritten, with all in-line assembler 
split off into separate .ASM files and 
the.code reorganized for clarity. 

The renderer requires only simple 
support (drawing) routines from the 
video drivers and integer math library 
to function. It should be much easier to 
add extensions to the renderer now. 

The PC interface and devices have 


been rewritten to be more robust in 
operation and to use new methods for 


joystick and timer control. New de- 
vices such as a key-status monitor im- 


prove the responsiveness of the user 
interface. 


The API 


One of the difficulties for programmers 
with REND386 was its many data struc- 
tures and the complex relationships 
between them. While this maximized 
efficiency of execution, it made learn- 
ing to program tough. 

Also, upgrading was made complex 
because many function calls depended 
on data structure capabilities. Finally, 
the extensive interdependencies of 
modules made modification or creation 
of new programs very difficult. 

To solve this, and to make adding 
future extensions possible, an API (ap- 
plication programming interface) was 
used as the basis for the VR-386 func- 
tion prototypes. The API hides much 
of the implementation of VR-386 from 
programmers (it is still available, of 
course, by direct programming). 

At this moment, the API is not yet 
fixed: the final form of the API is open 
for input.The API uses a few simple 
types to implement common opera- 
tions. 

These are the most important new 


types: .: 


OBJECT: combines visible objects 
(fixed and movable) and invisible mov- 
able “objects” (old segments) into linked 
object structures. OBJECTs can have 
types, be related and so on. 


POSE: rather than trying to handle 
position and motion by six variables per 
object, the POSE structure handles all 
motions and positions in the world. 
This structure will be crucial for the 
animation part of the API (under devel- 
opment). 


CAMERAS: these encapsulate the entire 





idea of drawing, stereoscopy, and view- 
points. CAMERAs have many charac- 
teristics, can be attached to objects, 
moved to a POSE, and so on. They are 
much like objects. 

Screen updating has been split off 
into several user-modifiable modules 
to preclear and add overlays to the 
screen after rendering. Stereoscopic 
cameras are supported transparently, 
and stereo rendering is even more flex- 
ible. 


LIGHTS: are an object-like item as 
well. They should be very extendable, 
and are supported by user-modifiable 
parts of the VR-386 code. For now, a 
single list of lights per world is sup- 
ported, but future versions may expand 
this. 

Three types of lights are supported: 
ambient, point (which may be posi- 
tioned), and directional spot lights 
(which are rotated). These lights may 
be moved or attached to objects as well. 


TELEPORTS: User movement is very 
important for flexible use of virtual 
worlds. The user’s body is now built in 
to VR-386 as the default, with the body 
consisting of a rotatable head for head- 
tracker support for HMDs, and move- 
able hand for glove or manipulator 
support. 

The body may be attached to and 
moved by objects in the world as well. 
By default, the body is invisible, but 
objects may be attached to it if desired. 

The TELEPORT is a way of formal- 
izing jumps in user position. This is 
used to implement the old “cameras” in 
REND386. CAMERAS are now dis- 
embodied viewpoints, which may be 
attached to visible objects if desired. 

The TELEPORTSs act to record and 
restore user positions in the world, and 
also restore body connections to mov- 
ing objects the body may have been 
“riding”. In the future, teleports will 
also be able to switch between 
WORLDS. 


Fe 
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WORLDS: Development of WORLDs 
is just beginning in this preliminary 
release. A world consists of visible 
objects, invisible objects, SPLITS for 
subdivision and visibility control, and 
inactive (hidden) objects. 

The idea of inactive objects is to 
remove objects from all world drawing 
and support, yet keep them available 
for quick adding and deleting. In the 
future, multiple WORLDs will be 
loadable, and entire WORLDS may be 
deleted from memory with with one 
call. 

The development of SPLITs from a 
minor visibility control role to an im- 
portant role in world design and motion 
control will be important in future re- 
leases as well. 


User Interface 

The user interface has been rewritten to 
make updates easier. The menu inter- 
face has been streamlined with a more 
modular key processing structure, bet- 
ter methods for cursor and screen res- 
toration, and so on. 

The ability to select objects with the 
mouse has been greatly simplified, and 
object vertices may be selected as well. 
Movement of the user via keys, joy- 
stick, and other devices has been inte- 
grated. 

All motion is now done with 
POINTER devices. and a navigation 
processor. These POINTER devices 
are common to 2D and 3D manipula- 
tion, and are simple to write. Future 
releases will integrate 3D navigation 
devices as well. In general, look at 
MAIN.C and KEYBOARD.C to see 
how to change the user interface. 


Modification of Software 
The most important goal of VR-386 
was to make it easy to create new 
programs that share most of the fea- 
tures of VR-386 while making it easy to 
drop or change unwanted features. You 
can see an example of this in the 


MINIDEMO project, which has only a 
few changed modules. 

These changes mostly drop support 
for the PowerGlove, simplify the menu 
interface, and automatically load and 
switch figures in and out of the world. 
Only a few modules are changed, and 
this entire project was done in less than 
2 hours. 

To start using the VR-386 code in 
your programs, read the VR_API.H 
file. This documents all of the API 
functions in more or less detail. Print 
out and read this file - you’! be glad you 
did! 

If you want to use the renderer core, 
print out RENDERER.H, and 
INTMATH.H for documentation of 
the integer/fixed/matrix/trig library. 


Development 
This release of VR-386 is meant for 
evaluation only. The idea is to gather 
comments on the API interface, to list 
future expansions and so on. If you 
write code with it, remember that some 
parts of the API may change soon. 
After this, API changes will only be 
addition of new functions.There are 
several steps to be done before final 
release. These include more comment- 
ing, use of the API types throughout the 
code, and adding some functionality. 
Changing of syntax of DOS C func- 
tions to Microsoft standard (i.e. dis- 
able() becomes _disable() ) will in- 
crease portability between compilers. 
The development of VR-386 will be 
more strict than REND386 was, to 
make it possible to integrate new capa- 
bilities into VR-386. If you ever want 
your code to remain compatible with 
(and possibly to be integrated with main 
releases of) VR-386, follow these rules:- 


NEVER modify any modules that are 
hidden by or part of the VR-386 API. 
You can change MAIN, KEYBOARD, 
and USCREEN, USERVID and 
COLORMAP if needed, but remember 
to rename these first. 





ANY other modules that are changes 
should be renamed, and any functions 
in them that are modified renamed as 
well. 


Best of all, have ONLY changed rou- 
tines in new modules. 


The idea is to be able to trace changes 
and their dependencies.- If you want to 
add basic features to VR-386, talk to 
Dave Stampe (dstampe@psych. toronto 
.edu) first. Someone else may be 
working on such a feature. 

It is also important to use an interface 
that matches the API, which should be 
designed and approved in advance. It’s 
amazing how interface specification 
affects how code is written.- Be effi- 
cient! 

There has been a lot of effort spent in 
VR-386 to use the fastest possible algo- 
rithms. If your code slows down VR- 
386, it will not be included or will be 
rewritten or replaced. Sorry, but there 
have to be standards. If in doubt, 
discuss your kernel code with me first. 

Also, please be concise with your 
code. There is no reason to create huge 
modules that duplicate existing func- 
tionality. 

Use the integer/matrix math library 
where possible. - 

Debugging: be sure your code is 
tested and causes NO crashes, and has 
no known bugs. I don’t really have 
time to debug code: in fact the hardest 
part of a development effort is in puz- 
zling out other’s code. 


Copyright and License 
This code is part of the VR-386 project, 
created by Dave Stampe. VR-386 is a 
desendent of REND386, created by 
Dave Stampe and Bernie Roehl. 

Almost all the code has been rewrit- 
ten by Dave Stampe for VR-386. Copy- 
right (c) 1994 by Dave Stampe: 


issue #14 March/April, 1994 PCVR 39 





Contact 
dstampe@psych.toronto.edu 


Dave Stampe is completing his doctor- 
ate at University of Toronto, and does 
a lot of contract programming and 
development. Most of this is in other 
fields than VR, but there is a lot of 
knowledge transfer to and from 
REND386. Dave is maintaining the 
VR-386 project for programmers. Send 
any code or comments to him. 


License 

May be freely used to write software for 
release into the public domain or for 
educational use; all commercial 
endeavours MUST contact Dave Stampe 
(dstampe@psych.toronto.edu) for per- 
mission to incorporate any part of this 
software or source code into their prod- 
ucts! 

Usually there is no charge for under 
50-100 items for low-cost or shareware 
products, and terms are reasonable. 
Any royalties. are used for develop- 


‘ment, so equipment is often acceptable 


payment. 


Attribution 


If you use any part of this source code 
or the libraries in your projects, you 
must give attribution to VR-386 and 
Dave Stampe, and any other authors in 
your documentation, source code, and 
at startup of your program. Let’s keep 
the freeware ball rolling! 


Development 

VR-386 is an effort to develop the 
process started by REND386, improv- 
ing programmer access by rewriting the 
code and supplying a standard API. If 
you write improvements, add new func- 
tions rather than rewriting current func- 
tions. This will make it possible to 
include your improved code in the next 
API release. YOU can help advance 
VR-386. Comments on the API are 
welcome. 
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Availability 

Currently, VR-386 is available on a 
trial basis by anonymous FTP from 
psych.toronto.edu, in the ~ftp/pub/vr- 
386 directory. The development pack- 
age is vr386.zip. Many new video 
drivers are available in video.zip in- 
cluding source code. 

A driver for the Cyberscope is avail- 
able as cyber.zip. This University of 
Toronto site has a much wider band- 
width than the Waterloo site: please let 
me know IMMEDIATELY ofany prob- 
lems! 


- Dave 
Stampe(dstampe@psych.toronto.edu) 


(EDITOR: The VR386 system is 
available for download from the PCVR 
Magazine Support BBS at (608) 877- 
0909. The system currently consists of 
four files and runs approximately 1.4 
MB.) 


After this "press release" was  publi- 
cized on the electronic services listed at 
the start of the article, a response was 
made by Bernie Roehl. 

Bernie will produce one more 
REND386 release. This release will be 
version 6.0 and will be used to basically 
clean up the system. After this release, 
Bernie expects to begin development of 
a new renderer. 














Virtual Reality and the 
Exploration of 
Cyberspace 


ne of the first things that 

struck me about ‘Virtual 

Reality and the Explora- 

tion of Cyberspace’ was 
its size! Its about twice as large as most 
other VR books to date. 

This is not necessarily indicative of 
quality however, and it appeared that 
one of the causes of its size was that 
Francis Hamit keeps repeating sub- 
jects. I was even more cautious when I 
found out that Francis Hamit is a tech- 
nical] journalist. On the whole I do not 
like technical journalists. They have 
struck me as being a rather parasitic 


The conclusion to the introduction 
is a fictional short story which is contin- 
ued throughout the book just to confuse 
the reader as to what’s fact and what’s 
fiction. If I had stopped reading there, 
as I was tempted, this review would 
have been nothing more thana damning 
criticism. 

At times the author does try to 
describe the technology involved in 
VR, and fails miserably, but where he 
succeeds is in general narrative. De- 
scriptions of the rise of certain VR 
companies makes interesting reading, 
and the history of VPL is one of the best 





By Robin Hollands 


drawings do get better), and a collec- 
tion of color pictures are included. A 
disk accompanies the book with com- 
munication software and free connect 
time to the DIASPAR Virtual Reality 
Network, a contour line flythrough of 
the Grand Canyon that was supposed to 
be in 3D (glasses included) which I 
could not manage to resolve, a collec- 
tion of 5 virtual worlds created with 
Virtual Reality Studio, and the now 
almost compulsory Superscape demo. 

All in all this is a very curious 
book. Some sections, especially the 
technical and philosophical ones, are 


Title : Virtual Reality and the Exploration of Cyberspace 
Author : Francis Hamit 
Publisher : SAMS 
Publishing Date : 1993 
ISBN : 0-672-30361-2 
Price : US$26.95 


Available from Computer Manuals in the UK on 021 706 
6000 or through your local bookstore - Please mention this 
review when ordering’ 


breed, taking the hard work and ideas 
of others and making a profit out of 
them. There are, however, a few 
exceptions, Howard Rheingold is one, 
Francis Hamit might be another. 

The introduction to the book did 
nothing to allay my fears. We are 
treated to a fuzzification of Virtual 
Reality which would lead most laypeople 
to wonder what all the fuss was about. 
This was accompanied by some of the 
worst drawings I have ever seen printed. 


Ive read. Teledildonics and virtual 
LSD are mentioned as well, but only in 
the capacity of investigating where the 
mythology had started. 

An outsider’s view of the VR com- 
munity is something a bit different, and 
Francis is even humble enough to dis- 
cuss the explosion in media interest and 
misinterpretation by his own breed. 

As is usual for VR books, the text 
is illustrated throughout (and the line 





complete rubbish. However the more 
journalistic chapters on the culture and 
immediate history of Virtual Reality 
are exceptionally good. 

If you want a technical manual on 
VR, then there are much, much better 
books around. If, on the other hand, 
you are looking for a modern-day suc- 
cessor to Howard Rheingold’s ‘ Virtual 
Reality’, then this is certainly worth a 
look. 


Sn rre rena nrraaaer eee TD IIE LLL ELI II IIOP AEE LP EE I ES 
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Virtual Reality Systems 


ased on an international 

conference in London, this 

book is a collection of es- 

says presented there, and 
others gathered subsequently. ‘ Virtual 
Reality Systems’ ‘brings together some 
of the leading practitioners and expo- 
nents in the field of virtual reality and 
explores some of the main issues in the 
area’. 

Whilst it is true that there are a couple 
of the big names in VR, most contribu- 
tors are relatively unknown researchers 
from obscure University departments. 
On the plus side, this means that you are 
presented with work actually being done 
in real laboratories by real VR workers, 
instead of the same old renditions of the 
history of VR and probable applica- 
tions. 

A brief history of virtual reality and 
survey of enabling technologies is given, 
just to set the ground for readers with no 
knowledge of the technology. You’ll 
also find representatives from some of 
the big VR system manufacturers, W 
Industries, Division and ARRL. How- 
ever, rather than provide anything use- 
ful, their contributions tend to be ad- 
vertising disguised as information. 

In stark contrast to this are the pre- 
sentations that are academically chal- 
lenging. Robinett and Rolland’s paper 
on mathematically correcting the dis- 
tortion introduced by HMD optics, and 
Friedmann, Starner and Pentland’s pa- 
per on ‘Device Synchronisation Using 
an Optimal Linear Filter’ both use quite 
complex mathematical principles. Be 
prepared to do some homework to 


understand these. 

Most of the other papers give general 
overviews of their fields of interest. K. 
Vaananen and K. Bohm show how 
gestures can be recognised using neural 
networks, and Papper and Gigante show 
what gestures can be used to control a 
robot arm. Papper and Gigante also 
show how physical constraints can be 
used to make manipulating virtual envi- 
ronment easier. 

Thalman shows how VR techniques 
and tools can be used to enhance com- 


Title : Virtual Reality Sytsems 
Author : R A Earnshaw, M A 
Gigante and H Jones 

Publisher : Academic Press 


Date : 1993 
ISBN : 0-12-227748-1 
Price : #29.95 (sterling) 





puter animation. Creating objects in 
virtual world is very easy if the object 
is known before hand, but P. Quarendon 
shows how a three dimensional object 
can be built up using a series of two 
dimensional pictures. Three dimensional 
VR techniques can be used to aid in the 
visualisation of complex information 
structures and FishEye techniques are 
introduced by Fairchild, Serra, Hern, 
Hai and Leong. An even bigger group 
of authors present AVIARY , an object- 
oriented operating system for VR ap- 
plications. 

The social implications of VR are 
discussed by Mallen, who examines its 


Book 
Review 


By Robin Hollands 


cultural perspectives, and Whalley who 
warns against the use of VR in treating 
mental disorders. Professor Kalawsky 
tells how to set up a VR lab, and also 
talks about visually coupled systems. 

As seems to be standard now, the 
book is illustrated throughout and in- 
cludes color pictures. An extensive 
bibliography is included as well as an 
overview of virtual reality software 
suppliers. 

For my money, the topics are too 
muddled and the information contained 
within not particularly useful, however 
‘Virtual Reality Systems’ would prob- 
ably be a welcome addition to most 
academic’s VR book collection. 
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Brad Burnett 


or the last two issues we have 

been discussing acuity and 

field of view. These are the 

two most important param- 
eters to know when evaluating a head 
mounted display because they deter- 
mine how much and how well that you 
see the virtual world. 

We define the correlation of acuity 
and field of view as pixels per degree. 
We gave examples of acuity and worked 
through the math. We gave an applied 
definition of acuity as the smallest part 
of an object that can be seen. 

The resolution of a head mount is 
determined by the amount of pixels in 
the horizontal and vertical direction of 
the display screen(s). A pixel is the 
smallest part of the display screen that 
can be controlled independently. How 
many pixels make up a virtual object 
dictates how clear the object will be. 
We rate acuity as a ratio of how the real 
object would look in the real world at 20 
feet to how far away it would have to be 
in the real world to appear as it does in 
the virtual world. We said that 20/20 is 
perfect, 20/200 and up is blind and 20/ 
100 is good for a head mount. 

When relating field of view to pixels, 
we know that the real world has 60 
pixels per degree. When we buy a 
display screen, the amount of pixels are 
constant. We can change the acuity by 
varying the field of view of the display 
screen to give more or less field of 
view, or pixels per degree. With pixel 
count or resolution constant, field of 
view is inversely proportional to acu- 
ity. 


Clearly, we have spelled out a trade 
off between two of the most important 
specifications for a head mounted dis- 
play. The more we sacrifice field of 
view to gain acuity, the more we give up 
immersion. Early head mounts have 
shown that the quality of the experience 
in a head mounted display is deter- 
mined by how much the user is im- 
mersed. While it is optimal to have as 
much acuity as can be afforded, the 
minimum amount required is depen- 
dent upon the task at hand. 

Since the acuity is determined by the 
amount of pixels per degree, we must 
find out the specifications for both 
resolution (amount of pixels) and field 
of view. The resolution of the screen(s) 
is always what is given, and what field 
of view is specified is left to be deter- 
mined. 


Would the Real Field 
Please Stand Up 


We referred to a software field of view, 
that is how much of the virtual world is 
supposed to be represented on the com- 
puter monitor. This amount can be 
quite deceiving if we consider a head 
mounted display with small optics that 
allows us to see only 40 degrees. Now 
let's say that we hook up a movie 
camera to this head mount with a wide 
angle lens. This lens will transport 70 
degrees of information onto the display 
screen in the head mount. The head 
mount optics still only occupy 40 de- 
grees of the physical field. 
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The sense of immersion is still only 
40 degrees despite the fact that there 
are 70 degrees of real information 
squashed into it. We are assuming that 
the designed 40 degrees is being met 
because our eyes are the proper dis- 
tance from the eye lenses, and the 
screen(s) are the proper distance from 
the optics. If there are any deviation 
from this optical field of view, the real 
or physical field is affected. 

When only considering the optical 
field, which is what most people do, 
the full resolution of the screen is 
specified. Most often, this practice is 
incorrect because we clip the screen to 
prevent the edges from being seen. The 
screen is also clipped if the screen is 
rectangular and the optics are round. 
Physically, as much as 100 pixels can 


true but in addition, each eye has a 


" unique view of objects in the periphery. 


If we havea pair of video screens side 
by side giving each eye 100 degrees at 
100% overlap, then the total field of 
view is 100 degrees. If there was 0% 
overlap, then the total field of view 
would be 200 degrees but rather impos- 
sible to see as one eye view would 
dominate. In this scenario, ifeach screen 
had 500 pixels, 0% overlap would 
cause the field to be comprised of 1000 
pixels. At 100%, the field would be 
made up of 500 pixels overlaid with the 
same information. 

In order to create a more natural 
vision with 70% overlap, we would 
find our information in the following 
way: 


1. Resolution per screen * 2 = 1000 pixels 
2. 1000 pixels * 70% overlap = 700 pixels overlapped 


3. Total resolution = pixels overlapped + (peripheral pixels * 2) = 





be set up correctly with consideration to 
the optical specifications. It just so 
happens to work out that overlap is one 
remedy for the centers of the display 
screens not lining up in a stereo head 
mount. 

At first glance it appears that the left 
and right images must be shifted hori- 
zontally but the process is a function of 
translation rotation as well as projec- 
tion. That is why it is very important 
that v. r. software can be custom set for 
different hardware. 


The Physical Field Of View 
We have now defined the three fields of 
view and consider the physical field to 
be the true one from an immersion 
standpoint. We looked at the math 


700 + 600 = 1300 pixels! 





get clipped from our screen with com- 
mon head mount practice (my solution 
in the Renegade HMD was to mold the 
optics rectangular). 


Overlap 

One way we can get our field of view 
higher, increase our resolution and 
make our image more natural is through 
overlap. In a head mount where each 






4 


eye sees the exact same amount of each 
image, it is considered to have 100% 
overlap. This is not to be confused with 
stereo depth perception. For stereo, 
each eye sees a slightly different angle 
of the same object depending on dis- 
tance. With overlap, this still holds 
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The eyes would perceive more field 
of view than in the scenario with the 
wide camera lens, and the vision would 
appear to be modeled more naturally to 
the way we actually see. The fact that 
the physical field would not be as 
dramatically affected seems to make 
this approach not very exciting but 
consider the following: 


1.) Fov per eye * %overlap =.100 * 70% = 70 degrees overlapped 
2.) Fov per eye - degrees overlapped = 100 - 70 = 30 periphery 
3.) Total field of view = (periphery * 2 ) + overlap 30 *2 = 60 + 70 = 130 degrees 


We have gained more field of view 
and more pixels and made the vision 
more natural all in one sweep. Unfor- 
tunately, there is a limit on a 60% 
overlap minimum before overlap be- 
comes distracting. Also, to make over- 
lap work correctly, the software must 


tem. We decided not to complicate the 
exercise with multiple lenses per eye 
but rather single lenses per eye. We 
acknowledge that multiple lenses are 
used to minimize distortion, but single 
lens formulas are fine for field of view 
exercises. 

Last time we designed a pair of lenses 
to work with 3 inch screens that had a 


behind designing a simple optical sys- | 
; 
' 
: 
. 






focal length of .96 inches and a diam- 
eter of 3.5 inches. The critical place- 
ment of the screens to get the image for 
our desired 15 inches to the eye and the 
magnification of 15.2 for our desired 
field of 110 degrees was .9 inches. 

In optics the screens would be called 
the object plane and the image would be 





called the image plane. The .9 inches is 
the object distance required to achieve 
the other desired figures. If any one of 


these parameters are changed even a. 


little, the differences in performance 
are monstrous. 

The other critical parameter for the 
optical setup is the distance from the 
eye to the eye lens (ocular or exit pupil 
as that is where the light exits the optical 
train) which is called eye relief. That 
affects the distance from the eye to the 
screen which in turn is related to the 
angle subtended to the eye. The head 
mount must be built durable enough to 
hold all of the distance within tolerance 
over time. - 

In our design we assumed that we had 
a 100% overlap as well as the axis of 
our eye aligning to the center of the 
screen. Now we will look at what 
happens if we sell our optics to a friend 
who wants to use them with 4 inch 
screens. Rather than being 2.75 inch 
horizontally like our 3 inch screens, 
this pair will be 3 inches. 

In this exercise we will assume that 
there is not a frame around the active 
area of the display screen as is the case 
with most video screens. The frame 
would add more distance between the 
screens. Without any frame, the screen 
centers are 3 inches apart from each 
other, as opposed to the eye axis that is 
2.5 inches apart. Our eyes can peer 
inward to converge an image without 
very much problem but in this case we 
are asking them to diverge which is not 
possible. 

We must offset the software optics 
and match up ourown screens. The way 
we will gain field of view is through our 
overlap. We will gain 16.74 degrees 
because of our 83.33% overlap bring- 
ing our total field up to 126.74 degrees. 
We could fill up an entire book talking 
about what would happen if we devi- 
ated from any other parameter. 

In our last issue we designed the 
optics from the screens conforming to 
our desired end parameters. This issue 


Neen a a 


we started with the optics and the screens 
to find our new parameters. My efforts 
are focused on the importance of cus- 
tom designing an optical system to meet 
the necessary requirements. I hope these 
last three articles have been helpful in 
determining the relationship of acuity 
from field of view and resolution. 

The information was conveyed ver- 
bally as well as mathematically so that 
you could extract as much as you want 
depending on the level that you wish to 
understand. Although there was a brief 
effort to review each previous article, 
all three are needed for a basic under- 
standing. Please contact PCVR to find 
out how to get back issues. 


Brad Burnett is the president of 
CyberSense Inc:, a head mount com- 
pany outside Madison Wi. He can be 
reached for comments at (608) 835- 
DELS: 
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Telepresence 


David Mitchell 
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ello & Merry Christmas! 


Of course, by the time you read this, 
the holiday season of Thanksgiving, 
Christmas and New Year’s will be 
over. But what’s a little time shift 
among friends... 

There are all kinds of good things 
happening in the world of tele-opera- 
tions. Much of it will be applicable for 
home-brew projects. 


In this column we’ ll look into what’s _ 


new in online video transmission and 
reception, the latest on the DC-X, what’s 
happening on the lunar moon base tele- 
operation project and talk a bit about 
how teleportation, telepathy and tele- 
time-travel may get a little bit closer to 
being possible in a few years. And, we 
can start thinking of ways that home 
tele-operations will create new services 
and money-making opportunities for 
BBS sysops. 


Do you get the picture? 
Up until now, poking around BBS’s, 
online systems and the Internet was 
largely a textual affair. You got to read 
words, lots of ‘em. That’s fine because 
there are a lot of people with worth- 
while things to say and this wired world 
is a great way to tune in and learn. 
Of course, you can download graph- 
ics, usually .gif files, and view them. 
And, for those with unlimited budgets, 
there are all kinds of video teleconfer- 


encing rigs. Nice if you have ISDN 
channels or TI links - but that rules out 
99% + of everyone on the planet at this 
time. 

So, what do you do if you would like 
to bounce a few video images back and 
forth with someone? Buy_a couple of 
picture phones at $1000 a pop and send 
one to a friend? Right...not! Well, how 
about using slow scan video imaging? 
One of the spin-offs of the Lunar Tele- 
operations Model project is low cost 
home video. If you have some kind of 
video source (camcorder; clunky old 
camera, security camera, VCR, etc.) 
and amonochrome frame grabber board 
for about $250, you can nowsend video 
images to others. 

The Dmodem software (free) used on 
Diaspar and for the LTM1 project re- 
ceives the video images and displays 
them immediately - leaving any text 
that was on the screen intact. So, this 
means there is a free comm package that 
receives video images. For about a 
tenth the cost of 2 video phones, you 
can have your own online video studio. 

You can email people images, send 
images real-time in chat (talk) sessions 
ononline systems that support the mode, 
post videos on BBS’s, etc. Since the 
software is free, this means tons of 
people can receive the images (nothing 
to buy - assuming they have a 386 or 
486 with VGA monitor) and only the 
video sender needs a frame grabber 
board. 

To make things really nice, Dmodem 
works with the IDEC frame grabber 
board to take the video snapshots (even 
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says “Say Cheese” and then “click”). 
And; Dmodem can send the data over 7 
bit Internet paths and uses no control 
characters. 

When receiving video, out of bound 
characters are ignored - making it pos- 
sible to email video snapshots to almost 
anyone anywhere on any system. So, 
there is now a home-brew video stan- 
dard, free software and several video 
modes from very compressed, minimal 
images (3K bytes) up to larger, pretty 
sharp images (18K bytes). 

And, there is even a free conversion 
program to convert .bmp and . gif files 
to the dmodem video graphics format 
(.dmg) files so you can send images 
even if you don’t have the $250 to buy 
the IDEC frame grabber board. 

Lots of new compression methods 
are being experimented with. By the 
time you read this, multi-frame image 
sequences should be working. All of 
this opens the way to low cost home- 
brew video. And, what better way to 
help get home Virtual Reality off the 
group than being able to have video 
chats and video email with people all 
over the world! 

Next time I will also have informa- 
tion on exciting work being done by 
some talented people in Canada with 
ultra-low cost home-brew video using a 
“dirt cheap frame grabber” and real- 
time video comm software. They said 
they need just a little more time to have 
their goodies operational. 


Fly me to the moon... 
Latest word I get is that continued flight 
testing of the DC-X experimental space 
ship has been approved. Remember, 
this is a 1/3 scale model of a true space 
ship. It proved we could build a space 
ship in 2 years, on budget, that is fully 
reusable like an airplane is. It's the 
future of space travel for most of us 
non-astronaut types. 

Being a tele-operated space ship, it 
means all kinds of things can be placed 


in orbit. Once you are in orbit, off the 
gravity pit we call earth, you are half- 
way to anywhere else in the solar sys- 
tem. Since the DC-X takes off and lands 
vertically, you could refuel it in orbit 
and then fly it to the moon. 

So, if we can ever get the government 


_to shake loose a bit of money for a real 


space ship, we also get a lunar landing 
capability thrown in for almost nothing 
extra! You can expect me to post video 
images of the DC-X from prior flight 
tests now that we have online video 
working. You won’t have to only read 
about it much longer. DC-X is such big 
news that the media misses it. Same 
thing happened when the Wright Broth- 
ers first flew - took years before the 
media understood the importance of 
what had been done. 


Model Lunacy: 

The lunar colony work is progressing at 
a good clip. We had a few firsts in the 
last month. The project leader, William 
Moore, drove the lunar rover from his 
home in Albuquerque, New Mexico 
and received video images from it. The 
rover was in my home in Southern 
California. After he drove it, everyone 
else took turns. Wehave done this twice 
now - each time with better quality 
images being sent for everyone to see. 

Next week we are having an LTM1 
model building party in which we will 
get a bunch of people local to the project 
to start assembling structures. This 
means that January looks great for the 
model to start limited operation. So, 
using the Dmodem software, anyone in 
the world will be able to tele-operate a 
lunar rover model on a miniature moon 
base soon! 

Last week we had students ata local 
high school get a demo of the whole 
setup. One of the things we hope to 
learn from all of this is how much one 
can do with low cost home tele-opera- 
tions, how good an image quality is 
needed and what kinds of things can be 


done. And, home tele-operations busi- 
nesses will spring up like crazy in the 
next few years. But, I’m getting ahead 
of myself, I’m saving that discussion 
for last! 


Beam me up, read my 
mind & give me a blast 


from the past! 

Ever wished you could be somewhere 
else at the snap of a finger? Ever wished 
you could talk with someone just by 
thinking? Ever wished you could go 
back in time? Not me! Never! You too? 
Sure, its silly - its impossible! But, 
wouldn’t it be a blast and a half? 
Fantasy aside, we are darn close to 
getting you 90% of the way there. 

We all know that Virtual Reality is 
going to open the door to simulations 
and experiences (sagas?) of this kind of 
thing. And, if two people in far corners 
of the world are both in the same virtual 
environment, wouldn’t they be for al- 
most all practical purposes able to do 
this? Sure. The trouble is it is an escape 
from reality. 

Roddenberry warned us of what can 
happen in the very first pilot for Star 
Trek, titled The Cage , in which a 
civilization got so involved in mind 
games they became useless and finally 
a race of voyeurs. 

So, what can we do? Well, tele- 
portation we solve by renting Android 
Agents at the remote location we want 
to visit. No more airplane tickets, rented 
cars and rented hotel rooms. Just dial- 
a-body, so to speak. Using VR to cut 
bandwidth and a good link not too 
different from that used to operate a 
radio-controlled, model race car. 

You end up with something like dial- 
ing a phone number, putting on your 
head-mounted display and gloves, and 
you walk out of a phone booth ready to 
take a tour, meet a friend, do business, 
etc. [bet in 10 years there will be a few 
experimental models. In 20, everyone 
will be doing it. Remember, some 


re TT 


Issue #14 March/April, 1994 PCVR 47 


people once thought telephones would 
never work for business. So, 
teleportation can be a reality for all 
practical purposes. 

So, how do we do telepathy? A 
telephone is darn near telepathy. The 
problem has been the phone cord. Up 
until recently, spread spectrum radio 
transmission and reception has been 
used by the military for super secure 
communications - but it’s about to be 
used in commercial applications. In- 
stead of sending all the info on one 
frequency, you send a bit on one fre- 
quency, a bit on another, etc. Makes 
jamming almost impossible and allows 
the signal to be a 100 times smaller than 
the noise level! It also means you can 
send signals using a few milliwatts of 
power. A small battery can keep you 
talking all day, : 

In 10 years, we can all have Dick 
Tracy wristwatch phones or rings or 
earrings or glasses or what-have-you's. 
With spread spectrum cell sites, digital 
encoding, etc. we will have practical 
telepathy - with an on/off switch! 


Ok, now the tough one - time travel . 


to the past. How do we do it? The main 
trick in time travel is to recreate the 
conditions. Suppose we want to recre- 
ate the sinking of the Titanic - an 
important lesson in- human nature, ship 
design, emergency procedures, human 
kindness and the need for communica- 
tion. 3 

Of course we will need virtual reality 
as a tool so that everyone involved in 
the event can experience it. We canalso 
build a Titanic from the ship’s design 
which is well known. See what we are 
doing? We build the scenario just like is 
done for a commercial software game. 
Not too different from: one of those 
“How To Hosta Murder” party-games. 
The difference is in the level of detail 
and world-building. 

But, you end up with the ability to 
relive history and also try alternate 
scenarios. The more original intorma- 
tion we have, the better the ability to do 


time-machine work. Virtual Reality is a 
major time-machine lever. And, home- 
brew VR will allow home world-build- 
ers to recreate historical events in ways 
not too different than historical diora- 
mas are put together now. 


There’s Gold in Them 
thar Virtual Hills - The 


Tele-Service Industry! 

Eventually, people will start actually 
making money in the field of Virtual 
Reality. No one really knows who will 
be the “Bill Gates of Virtual Reality” 
and it doesn’t really matter. What is a 
given is that like in any new field, there 


~will be 9 failures for every | success 


and that a lot of home-brew business 
will be tried. 

Some will succeed. A few will suc- 
ceed wildly. Big VR will require big 
efforts. Home-brew tele-operations 
works Well for small projects and small 
groups and motivated individuals. Small 
VR will make individual world-build- 
ing possible. 

In the Tele area, imagine being able 


to offer manual labor services without 


having to leave your home. Things 
like: Midnight housecleaning, Any- 
where security patrols, Tele-muds, tele- 
toys and tele-games. 

Say what? From your home, you 
could operate remote Androids that do 
work to help people - anything from 
gardening to vacuuming - there is no 
such word as handicapped in this indus- 
try. From your home, you could build 
dolls and toys that can be tele-operated. 
. Grandpa David could say “HI” to his 
grandson by tele-toy. A BBS sysop 
could let people drive a toy car through 
atele-mud-maze. You could offer street 
or home security patrol service. There 
is no limit to the number of offerings the 
tele-service industry is about to un- 
leash. Stay tuned for more about this in 
future columns. 


Tele-future 

Next column we’ll be exploring the 
tele-service industry in more detail, 
getting updates on all the projects and 
we'll look at more things the interested 
individual can do to get involved in 
home-brew tele’ing. 


“Mitchell’s law: Everyone should have 
at least one Android Agent.” 
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Graphics 





Bob Pendleton 


f you’ve ever looked into doing 
register level programming on an 
SVGA display the firstthing you’ ll 
notice is that while all VGA dis- 
plays are quite compatible with each 
other, SVGA displays made by one 
manufacturer are not compatible with 
SVGA displays made by other manu- 
facturers. In fact, SVGA displays made 
by the SAME manufacturer may not be 
compatible with each other. 

This lack of compatibility is a prob- 

lem for anyone trying to write graphics 
programs that take advantage of SVGA 
displays. If you want your program to 
be usable on all PCs you have to write 
special code for each of the different 
SVGA displays on the market. Bennett’s 
"univbe" (pronounced “uni-vee-bee- 
ee) documentation lists more than 40 
different kinds of SVGA displays made 
by 18 different manufacturers. 
It takes a lot of programmer time, 
which translates into a lot of money, to 
support 40+ different kinds of dis- 
plays. That means that only a few very 
popular software products support all 
those different displays. It means that 
individuals and small companies don’t 
even try to write SVGA software. This 
is a problem that needs a solution. 

VESA, the Video Electronics Stan- 
dards Association, is a group of 140+ 
companies that all have a monetary 


stake in the PC graphics market. VESA 
is the organization that developed the 
VESA Local Bus (VLB) specification 
that is giving PCs fast 32 bit video 
displays and peripherals. VESA has 
developed a number of different stan- 
dards that affect all current and future 
PC owners. 

VESA solved the SVGA compatibil- 
ity problem by developing a standard 
set of extensions to the video BIOS that 
make it easy to write programs for 
SVGA displays. VBE (VESA BIOS 
Extensions) is a set of 9 BIOS calls that 
hide the differences between SVGAs 
while letting each manufacturer add 
features that add value to their prod- 
ucts. A perfect solution for end users, 
programmers, and graphic hardware 
manufacturers. 

VBE should have been the solution to 
everyone’s SVGA problems. Unfortu- 
nately, not all manufacturers support 
the VBE standard, and those that do 
support it support different versions. 
There are 3 different versions (1.0, 
1.1, and 1.2) of the VBE specification 
and version 2.0 is under development. 
What was needed was a universal ver- 
sion of the VBE. A single TSR that 
would recognize what kind of SVGA 
was in a system and provide support for 
the latest version of VBE for all SVGA 
cards. Univbe, written by Kendall 





issue #14 March/April, 1994 PCVR 49 








Univbe is a TSR (Terminate and Stay 
Resident) program that you can load 
from your autoexec.bat file that pro- 
vides a standard VBE | .2 interface for 
just about all the different SVGA cards 
in use in the world today. With univbe 
we can write SVGA graphics programs 
and expect them to be usable by people 
all over the world. 


VESA BIOS Extensions 
The VBE isan extension to the video 
BIOS. The video BIOS is called by 
putting commands in CPU registers 
and invoking interrupt 10h. The VBE 
extends and replaces the standard inter- 
rupt 10h BIOS calls. What follows is a 
list of the VBE calls and a brief descrip- 
tion of each one. For more details look 
at the code in vbe.cpp. 


Function OOh - Return Super 
VGA Information 


The first problem you ha‘e when pro- 
gramming SVGA graphics is finding 
out what the SVGA you are using can 
do. Function 00h returns a pointer to a 
vbelnfo record (defined in vbe.h.) Use 
this call to find out-whether or not you 
have VBE support, which version of 
the VBE itis, who wrote the VBE 
you’ re using, how much video memory 
you have, and which VESA video modes 
are supported. 


Function O1h - Return Super 
VGA Mode Information 

This function returns details about a 
specific videomode. It returns a pointer 
to a vbeModelnfo record (defined in 
vbe.h.) This: record gives you all the 
information you need to do graphics in 
that mode. 


Function 02h - Set Super VGA 
Mode 

This function lets you set the video 
mode that-you want to use. Despite its 
name, you-can-use this function to set 


any of the standard VGA video modes 
as well as the VESA SVGA video 
modes. Thecurrent VESA video modes 
are listed in Tables | and 2. 

In the tables “k” means 1024 and 
“m” means 1,048,576. Video modes 
with 32k or 64k colors have 15 and 16 
bits in each pixel and modes with 16m 
colors have 24 bits per pixel. Remem- 
ber that just because VESA standard- 
ized all these modes doesn’t mean that 
using the VBE will let you use these 
modes on all displays. 

The “query” function of the demo 
program on the disk uses function 02h 
to find all the VESA modes supported 
by your SVGA card and writes detailed 
information about them to a file. Note 
that your SVGA card might support 
video modes that your monitor can’t 
handle. 


Function O3h - Return current 


video mode 

Use function 03h if you want to know 
what the current video mode is. I use 
this one just before I set a high resolu- 
tion mode so that when my programs 
are finished they can restore the video 
mode. It’s not nice to leave the display 
in some weird video mode. Makes 
users irate. 


Function 04h - Save/Restore 
Super VGA video state 
Multitasking operating systems and 
TSRs can use this call to save every- 
thing in the current display state so they 
can change to a different mode, use the 
new mode, and then put everything 
back the way it was. 


Function 05h - CPU Video 
Memory Window Control 

When the original IBM PC was. de- 
signed, 64k was a lot of memory and a 
megabyte was so big that slang for a 
meg was “Moby” as in the size of the 
great white whale. Designers of the PC 
allowed for 640k of RAM, 64k for 


color graphics and 64k for monochrome 
graphics. They were planning for the 
future. 

We live in the future. We live way 
past what the designers planned for. 
VESA video mode 11Bh lets you dis- 
play 1280 pixels by 1024 pixels with 24 
bits (3 bytes) of color per pixel. An 
SVGA that supports mode 11Bh must 
have 3.75 megabytes of video memory. 
That’s 6 times the 640k the original PC 
was designed to support and 60 times 
the 64k that is allocated for color graph- 
ics. Even a simple | meg card that 
supports the 1024 x 768 256 color mode 
has 16 times 64k of display memory. 

So, how do you pack a megabyte of 
display memory into the 64k allocated 
for color graphics? You break up the 
big memory into a bunch of pages that 
you can map into the 64k you have one 
chunk ata time. The VESA doc uses the 
term “memory windows” to describe 
this technique. I prefer to use the term 
“memory banks” to avoid confusion 
with graphics windowing systems like 
Windows and X. 

Every SVGA provides some way to 
map its video memory into the PCs 64k 
graphics space one or more chunks ata 
time. The trouble is that they all do it in 
different ways. This is the most impor- 
tant problem the VBE solves. VBE 
gives you a way to select which bank is 
mapped in without having to know how 
each different SVGA does the map- 
ping. It also tells you how many banks 
are available. 

To give an example of how the banks 
work consider how you draw a pixel at 
location x =537, y=323 in the 640 x 
400 256 color mode. The address of the 
pixel in video memory is given by 
(width * y) + x. In this case that’s (640 
* 323) + 537 = 207,257. Assuming 
64k byte banks this pixel is at byte 
10649 in bank 3 (207,257/65536 = 
3+ 10649). So, to draw the pixel you 
use function O5h to map bank 3 into the 
PCs graphics space and store a byte 
10649 bytes into the bank. Look in 
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vg.cpp at the “pixel” function for de- 
tails of how to do this. 

Not all SVGA cards support 64k 
banks. Having to deal with several 
different sizes and layouts of memory 
banks complicates programming with 
banks. But, Bennett’s univbe makes all 
banks look like they are 64k long. This 
is one of the nice features of univbe. 


Function O6h - Set/Get Logi- 
cal Scan Line Length 


This is a nice feature supported by most Resolufon Colors 
SVGA cards. You can select a video 
mode that displays say 800 x 600 pixels ie t fe: 
on the screen and then tell the SVGA 5 
: 640 x 480 
that the frame buffer lines are actually 800 x 600 
1024 pixels long. 800 % 600 

This means that the 800 x 600 is a ee 768 
window into a larger viewable region. y: 

; 1024 x 768 
If you have 1 meg of display memory 1280 x 1024 
and tell the SVGA that logical scan lines soe ie — 
are 1024 bytes long, the 800 x 600 is a ‘ 

? : : : 320 x 200 
window into a logical screen that is 320 x 200 
1024 x 1024. You can draw into the + 

: ; 320 x 200 
whole logical display and then use VBE 
: 640 x 480 
function 07h to make any part of the 
; : P 640 x 480 
logical screen viewable in the 800 x 600 
pixels that are displayed on your screen. G10 x. eet 
800 x 600 
2 800 x 600 
Function O7h - Set/Get 800 x 600 
Display Start 1024 x 768 
This function lets you choose which 1024 x 768 
part of the logical display is viewable on 1024 x 768 
the screen. You can use this function to 1280 x 1024 
do smooth scrolling or to do “page 1280 x 1024 
flipping” to get smooth animation. The 1280 x 1024 
setVisiblePage function in vg.cpp uses 
this function for just that purpose and Table 1 
the pixel and rect demos in demos.cpp VESA SVGA Graphic Modes 


use set Visiblepage. Look there for ex- 
amples of how to use function O7h. 





Function O8h - Set/Get 


DAC Palette Control 

The standard VGA color palette has 6 
bits of red, green, and blue per color. 
Many SVGAs support 8 bits for each of 
red, green, and blue. Function 08h is 
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used to find out the current width of | demo rect - Draws random colored 


colors and to-select a different width. rectangles on the screen in 640x400 
256 color mode. Writes the number of 
Software frames/second to the result file. 


All the code that is included with this 

article require an SVGA display with References: 

VBE 1.2 support. Use the univbe TSR = VESA Super VGA Standard, Video 
even if your system already has VBE Electronics Standards Association. 
support. 

The software can be found on the ~Programmer’s Guide to the EGA and 
PCVR Magazine Support BBS at 608- VGA Cards”, Richard F. Ferraro, 2nd 
877-0909. The name of the file is ed. 1990, Addison-Wesley, ISBN 0- 
il4graph.Izh. 201-57025-4 

Before running the demo program he 
you need to unzip univbe42.zip and 
install univbe.exe. Installation instruc- 
tions and other interesting documenta- 
tion can be found in the doe directory 
that will be created when you unzip 
univbe. Run the demo program like 
this: 








demo query - Writes a description of all 
the VESA video mode supported by 
your system to a file named “result” in 
the current directory. 


demo 332 - Draws 256 different col- 
ored rectangles on your screen. 


demo pixel - Draws random colored 
pixels on the screen in 640x400 256 
color mode. 


To find out what, if any, VBE support 
you have in your system and writes the 
number of frames/second to the result 
file. 


Mode _ Resolution 


108h 80x 60 
109h =132 x 25 
TOAh 132 x 43 
10Bh 132 x50 
10Ch 132 x 60 


Table 2 
VESA SVGA Text Modes 
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Making REND Work 





Chris Kwasnicki 


ello once again to Making 
Rend Work. Currently we 
are developing a VR simu- 
lation of firemen respond- 
ing to the World Trade Center bomb- 
ing. As the name implies, we are using 
the freeware package REND386 as the 
engine for this model. We have in place 
a representative model of the site of the 
bombing, including most of the sur- 
rounding buildings and roadways. 

Last time, a three level garage, simi- 
lar to the one where the bombing actu- 
ally took place, was added. Included 
was the ability to limit the cybernaut’s 
movement, and automatic height ad- 
justment as the cybernaut moved from 
level to level via ramps. 

This time around, we’ll be working 
on the first level of the garage. We'll 
place some cars, develop a method for 
simulating smoke, and help keep the 
refresh rate up by giving REND386 
some helpful hints. 


| CAN SEE YOU.. 


The world went over 1000 polygons 
this time around. The specs are as 
follows: 1075 polygons, 1339 vertices, 
85 objects, with approximately 40,000 
bytes free. This makes WTC.WLD a 
fairly large sized world (but by no 
means the largest). And it will only get 


larger, as more details to the garage 
area are added in. The frame rate for 
this world varies greatly, usually be- 
tween 5 and 12. (Development plat- 
form is a 40MHZ 486DLC using ISA 
16-bit VGA). Why the variation? 

As mentioned last time, REND386 
uses a painter’s algorithm for placing 
objects. It paints what it thinks is the 
furthest object from the cybernaut’s 
viewpoint and works it’s way back to 
the closest. In this way distant objects 
are drawn over. This means if there are 
100 identical boxes lined up in a row, 
and you are standing at one end of the 
row, REND386 will paint the furthest 
box, then the next furthest, then the 
next, andso on. 100 boxes are painted 
over each other to show you one. This 
is an extreme example, so let’s go the 
VR app! 

When WTC.WLD begins, the 
cybernaut is standing inan empty room, 
facing a fire pole. Frame rate is be- 
tween 12 and 13, very good. Now 
swing your viewpoint to your right, and 
watch as the frame rate drops, here to 
5 asecond. Not good. Why? When 
you were facing the fire pole, there 
were only a few objects that REND386 
needed to paint - the firehouse and the 
fire pole. Once you rotated right, 
REND386 must now paint not only the 
firehouse, but most of the World Trade 
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Center complex - all the buildings, the 
three garage levels, the cars on level 
one - all of it. 

What does this mean to a REND386 
world builder? How can this perfor- 
mance hit be avoided? Knowing alittle 
about how REND386 handles things 
internally will help. REND386 at- 
tempts to disqualify objects from fur- 
ther processing as soon as possible. 

Before performing all the calcula- 
tions needed to place an object onto the 
screen, REND386 will calculate the 
object’s center position and size of an 
enclosing sphere relative to the viewer’s 
eyepoint (enclosing sphere means a ball 
that would totally surround the object). 
If no part of the sphere is in the 
cybernaut’s field of vision, REND386 
can safely ignore the object. This 
means it doesn’t need to calculate all the 
vertices. 

In WTC. WLD this means an average 
18 vertices calculations REND386 
doesn’t have to do per object ignored. 
So when facing the fire pole, REND386 
needs need to perform a center calcula- 
tion with many of the objects - just 
enough to know it could safely ignore 
them. In addition, REND386 uses this 
sphere to checks objects against a "yon" 
clipping range. Set in the .WLD file, 
the yon range specifies a distance at 
which objects are to be ignored. Any 
object further from the viewpoint than 
this value are eliminated from the pro- 
cessing pipeline. 

I mentioned this information so that 
you have it when designing your own 
worlds. Unfortunately, it doesn’t help 
here since we are trying to model a 
specific place with reasonable accu- 
racy. This requires specific objects 
locations. Also, the yon value won’t 
help much. Currently set to 900000, it 
could be made smaller. 


The unfortunate side effect of this is 
that large objects can just “pop” up. 
And it is tough to calculate a yon 
clipping that works well from all pos- 


sible viewpoints. For example, in the 


Take the following code: 


object house=simple.plg 1,1,1 0,0,0 0,0,0 . colormap 


object house =complex.plg 1,1,1 0,0,0,0,0,0 20 colormap 





room, we want to clip the buildings. 
But right outside, on the fire truck, we 
need to see them. 

What method(s) does REND386 pro- 
vide to the world builder for perfor- 
mance enhancing? Designing efficient 
.PLG files is very important (and time 
consuming). Different faces (poly- 
gons) of the same object should share 
the same vertex, not have separate 
copies. This is where PLGX, a utility 
supplied with the release V5 of 
REND386, is important. 

The /V option will identify and com- 
bine duplicate vertices. Important to 
note is that some CAD packages may 
generate multiple but identical vertices, 
as well as two faces for each surface you 
define. If you don’t need both faces of 
a particular surface, get rid of one! 

NorthCAD, the package I use, does 
this, requiring doctoring of the output. 
The final performance booster is to use 
world file’s “addrep” command. This 
command allows one to automatically 
use different representations (.PLGs) 


Here we defined two .PLGs for the 
same object, house. Assume that 
complex.plg holds a house description 
that describes doors, windows, and 
other details, and uses many points and 
faces. Simple.plg is simply a box, 
maybe a roof on top, described by few 
points and faces. 

If the screen representation of house 
is larger than 20 pixels, REND386 will 
automatically use complex.plg to dis- 
play the house. However, if house is 
far enough away that, when painted, it 
would be smaller than 20 pixels wide, 
it will use simple.plg. This increases 
rendering speed as REND386 doesn’t 
waste time painting details too small to 
see. 
Luse this feature in WTC.WLD with 
the object feng (FIRENG.PLG). It 
consists of 124 faces using 106 verti- 
ces. I constructed a second .PLG called 
firengsm, which leaves out details (like 
the rear handholds and the window 
detailing) and set it up in the .WLD file 





of an object, based on distance from the 
user. So the world builder can define a 
less complicated (less vertices and poly- 
gons) .PLG for when the object is 
distant. 

The syntax is addrep name= filename 
SX,Y,Z TX,Iry,tz tx,y,z size map. The 
parameters are similar to the object 
command, with one difference. The 
size parameter specifies the minimum 
screen size to be used for this represen- 
tation. 


FIRENGSM.PLG has only 40 verti- 


ces and 20 faces. Whenever the 
cybernaut is far enough away, the en- 
gine won’t be as detailed. In this case 
this means 104 faces and 66 vertices 
that don’t need to be dealt with. 
There are (of course!) several draw- 
backs to this system. One is creating 
and keeping track of duplicate .PLG 
files for one object. (This is easiest 
when using a CAD package, but there 
is a method for combining multiple 
representations of an object in one file). 


a I 
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Second, each additional object, or it’s 
representation, takes up memory. This 
world is rapidly approaching the 
memory limits, with much more to do. 


Hint, Hint.... 

Even with all these techniques em- 
ployed (truth be told, some of the .PLG 
could stand more work), the frame rate 
can get pretty bad. Standing outside the 
garage is about 5 frames a second. 
Inside the garage is about 5-8 frames, 
depending on the direction you’ re look- 
ing. 

So I have decided to implement a new 
animation language command called 
showarea. 

The formal declaration follows: 


showarea (x) areaname 


This command will specify 
whether to render any object 
located within the area, created by 
splits, specified by areaname. If 


X=0, all object for areaname are 
ignored. If X=1, all objects for 
areaname are considered for 
rendering. At startup all objects 
in all areas are visible. 


With one command, we can ignore 
all objects associated with one area, 
instead of using memory describing 
multiple object representations. For 
the type of world we are modeling, this 
commands works out very well. If we 
are standing in the garage on area 
levell, we know for a fact that we will 
be unable to see any of the objects 
associated with area level2. 

We can simply issue the command 
“do showarea(O)level2”. All objects 
within level2 will be ignored for ren- 
dering purposes, and hence frame rates 
will increase. Of course, we need to 
issue an “do showarea(1)level2” com- 
mand if we wish to see objects on level2 
again. 

There is another important reason I 





implemented this command. It allows 
one to eliminate some visibility errors 
efficiently. The biggest visibility prob- 
lem with the current world is seeing the 
garage area from above ground. 

In the world discussed in the last 
issue, if you were standing in front of 
the Vista garage, you could clearly see 
the garage. Part of the problem was an 
inefficient .PLG file. The faces of the 
garage wall’s facing out (that is, if you 
are inside the garage, the opposite side 
of the walls surrounding you) shouldn’t 
be defined. NorthCAD automatically 
created these faces. 

But even if removed, there is the 
problem of the floors and ceilings. 
Since these interconnect the levels, both 
sides must be defined. Hence, you will 
see the floors very clearly from above 
ground. One solution to this is to place 
a polygon to act as the ground. This is 
what I did in front of the Vista for an 
example. 

However, this doesn’t help perfor- 
mance atall as not only are you drawing 
the garage, you’re drawing the ground! 
With the showarea command, we can 
make the underground section invis- 
ible, until we enter it. Eliminates 
visibility problems and speeds up the 
frame rate. 

By going this way, I didn’t need to 
place a polygon between Liberty St. 
(road in front of the firehouse) and the 
Vista, as last issue the garage was very 
much visible during the ride. 

So howis this technique implemented 
in WTC.WLD? Last issue I introduced 
an animation which kept track of the 
cybernaut’s location. I'll modify this 
oneto provide showarea support. Please 
refer to the animation example in Fig- 
ure*le 

In the state init, I use the showarea 
commands to ignore for rendering pur- 
poses areas levell, level2, level3, 
leftramp, and rightramp. This im- 
proves frame rates from 5 to 9 when 
you swing your view right at the start 
point. Now if you ride the firetruck to 


the bomb site, you end up standing 
outside the Vista. 

Here the frame rate is around 10. If 
you were to comment out the above 
“showarea(0)” commands, the frame 
rate would drop to 6. About forty five 
percent improvement - not bad. I also 
use the showarea to turn on certain 
areas. I did this for documentation 
purposes, as the default is for a state to 
be visible until turned off. Finally, a 
sensor command checks to see if we 
moved into the area. Ifso, the next state 
executes. 

Depending on the sensor and usrlimit 
commands (described last issue), this 
animation will be in a specific state 
whenever the cybernaut is within the 
usrlimit parameters. Since we are mod- 
eling large enclosed spaces, we will 
have REND386 ignore areas that we 
know are not visible. So, for state 
“frontvista”, since the cybernaut can- 
not possibly see levell, 2 ,3 and the 
ramps, we shut these off. 

State “entramp” is where the 
cybernaut can possibly see levell and 
the ramps, so we turn these on with a 
showarea(1) command. In state 
“levell”, areas houtside, loutside, and 
frontvista are shut off. This animation 
is double ended - moving backwards 
through the states will reverse the or- 
der. 


Oniy Coders Need Apply.. 
I won’t describe the rest of the anima- 
tion, but the same basic procedure is 
used throughout. The code used to 
implement this command is included 
with the file distribution (do a search 
for “CFK” and “SHOWAREA” to find 
the changes in the .C files). I won’t go 
into details here (see last issue for a 
description of hooking in new com- 
mands). 

Basically, I added a new flag (ignore) 
to each area’s data structure, which is 
simply set true or false. When 
REND386 starts drawing, it will check 
this flag. If ignore is true, REND386 
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ANIMATION EXAMPLE 
animation 20 
state init 
do showarea(1)frontvista 
do showarea(0)levell 
do showarea(0)level2 
do showarea(0)level3 
do showarea(1)entramp 
do showarea(0)rightramp 
do showarea(0)leftramp 
do showarea(1)houtside 
do showarea(1)loutside 
do sensor(....)[state=frontvista] 
state frontvista 
do showarea(0)level1 
do showarea(0)level2 
do showarea(0)level3 
do showarea(0)rightramp 
do showarea(0)leftramp 
do sensor(..)[][state=entramp exit] 
do usrlimit(....) 
state entramp 
do showarea(1)levell 
do showarea(1)entramp 
do showarea(1)rightramp 
do showarea(1)leftramp 
do showarea(1)houtside 
do showarea(1)loutside 
do showarea(1)frontvista 
do sensor(...)[][state=levell exit] 
do sensor(...)[][state=frontvista exit] 
do usrlimit(...) [J] 
state level1 
do showarea(0)houtside 
do showarea(0)loutside 
do showarea(0)frontvista 
do sensor(...)[][state=entramp exit] 
do sensor(...)[][state=rtopramp exit] 
do usrlimit(...) 0] 
state=rtopramp 


Figure 1 


issue #14 March/April, 1994 PCVR 










skips this area. Otherwise, draw it. 
The code snippet in Figure 2 shows the 
parse section of the new command. 

I used the “poptext” command as a 
template for this command. Assume 
this code is parsing the command “do 
showarea(l)entramp”. Line 1 parses 
the “showarea”. Line 2 will parse the 
“(1)”. Line 3 will parse any “[]” 
commands, which we don’t have here. 
Line 4 parses the area’s name, 
“entramp”. Line 6 is of interest here. 
When REND386 parses the .WLD file, 
certain symbols are stored, as well as 
their corresponding values. The func- 
tion find_name() will return the value, 
depending on what the object is. Here, 
since we pass it the list of areas, it will 
return the address of the structure asso- 
ciated with the given name. This is then 
passed at runtime to our command for 
execution. 


Where There Is Fire... 


If you saw the video news accounts of 
the real life bombing, you remember 
that everybody was just absolutely cov- 
ered in smoke and soot. A great deal of 
it poured out of the Vista garage, and 
we need to simulate that. 

Due to memory limits, rendering 
speed, and general lack of artistic abil- 
ity, the “clouds” of smoke here will 
simply be defined as large polygons, 
described in CLOUD.PLG. Six such 
clouds are defined in WTC.WLD, as 
objects smokeO1 through smoke06. 
Each smoke object has an animation 
controlling it. Smoke01’s animation is 
shown in Figure 3. 

This animation steps through several 
states, to move the smoke01 object 
from the back of the ramps intercon- 
necting the various levels, across the 
floor of level1, up and out the garage 
entrance. It then loops backs. State 
“init” sets a timer (different value for 
each smoke animation). Once the timer 
Tuns out, it moves on. State “onramp” 
moves the object to a known position. 

State “ingarage” uses the step com- 








mand to move the cloud, independent 
of frame rate, across the garage. The 
postest command tests if we have moved 
outside the defined area. If so, next 
state. States “upramp” and “up” are 
variations on “ingarage” - we move the 
object (up the ramp and then straight 
up, respectively), and go onto the next 
state. 

State “up” loops back to “init” , where 
we Start the process all over. This is a 
simple way of providing motion to the 
world. This basic routine can be used 
whenever you wish to send an object 
along a predefined path. And through 
the use of variables, the path could be 
altered. A good exercise would be to 
modify the animation so that smoke 
doesn’t leave the garage until the open- 
ing is cut. 


Odds and Ends... 


For good measure I placed several cars 
(like the colors?!) on level one. This 
issue's features the return of 
“metalman” from ROOMS.WLD as 
well. He is lying on the floor, uncon- 
scious. Helping him will bea story for 
another time. 


Distribution... 

The complete set of files to run this 
world are available from the PCVR 
Magazine Support BBS at 608-877- 


CODE SNIPPET 


1] else if (!stricmp(var, “SHOWAREA”)){ 
2] s->xi = getarg(c, 180, 90); 
3] cr = parse_assgn(cr, s, 1); 


4] c = strtok(cr, “#\n”); 

5] if (!c) return; 

6] s->yl = (long) find_name(areas,c); 
7\ if (s->yl1 == (long) NULL) return; 
8] s->type = SHOWAREA; 

OTF 


Figure 2 


1017. - please seethe README.TXT. 
Also included are the source code rou- 
tines from the DEVELS.ZIP (the source 
code distribution of REND386) which 
have been modified. 

Also included are the .NC3 files 
generated by NorthCAD, for those 
readers who use it. Note that running 
these .NC3 files through the PLG con- 
version facility will not generate .PLG 
files identical to the ones in the distribu- 
tion. Many of the .PLG files have been 
modified by hand for performance rea- 
sons. Still, the .NC3 files are a good 
start for your own modification. 





Till Next time... 


Hope you found this information useful 
in creating your own worlds. Nexttime 
we’ll get away from creating the trap- 
pings of this world and more into what 
this world is an attempt at - to create a 
VR simulation of a specific training 
exercise. Any questions or comments 
can be directed to kwas@panix.com. 
Take care. 


SMOKE ANIMATION 


state init 
do timer(1)[exit][state=onramp] 
state onramp 


do smoke01 = moveto(-71355,-2500,84000 x,x,x) igtate —-ingarage} 


state ingarage 
do smoke01 =step(x,x,-3000 30,40 


,50)[ ] 


do smoke01 = postest(x,x,40000, x,x,300000) [state=upramp]| ] 


state upramp 


do smoke01 =step(x ,950,-3000 31,41,51)[ ] 
do smoke01 =postest(x,x, 19000, x,x,39999) [state= upll ] 


state up 


do smoke01 =step(x,4000,x 32,42,52){ ] 
do smoke01 = postest(x,0,x, x,40000,x) [state=init][ ] 


Figure 3 
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ince working with VREAM 

is so much fun, we’ re going 

to continue the light-hearted 

introductory discussion we 
started last month and see if we can find 
a way to keep enjoying ourselves while 
we get more prepared to ride into the 
mists of 3D thinking. 

In this column, we won’t actually 
climb up on the stallion, but we’! walk 
around the steed and examine some 
more of the surroundings, like the turf 
under its feet and the conditions of the 
roadway and the track. We’ ll be look- 
ing out of the corner of our eyes for 
hitching-posts we cantie our3D thoughts 
to, and, while we saunter along, we’ll 
be keeping our eyes peeled for any sign 
of dangerous potholes or ankle-twist- 
ing rocks which might trip us up and 
provoke a frustrating delay in our jour- 
ney. 

Thinking in three dimensions (3D) is 
the destination of our travels, and pre- 
paring well for the start of our explora- 
tion will improve the odds of arriving 
without undue difficulties. Using 
VREAM (or, indeed, any virtual real- 
ity software) requires a robust ability to 
think competently in three dimensions, 
so we need to practice until we’re 
skillful with it. 

Let’s begin by standing next to our 
trusty beast of burden and look straight 


ahead at the pathway. If you could 
draw a yellow line right down the 
middle of the dusty road, you would 
havea handy reference line. You could 
say “I’m going to ride my horse and 
follow that yellow stripe”. If you said 
that, I could understand clearly what 
you meant (assuming I was there with 
you). I would know exactly which 
direction you intended to pursue. 

In fact, I could respond “Oh, you’ re 
going to follow the path line”, and you 
could nodand say “Exactly so”, and we 
could share the warm feelings of achiev- 
ing lucid communication while we won- 
der why we sound suspiciously like 
Laurel and Hardy, silently relieved that 
it wasn’t a yellow brick road. 


“PATH LINES” 


Such a successful moment calls for 
another spine-tingling experience, so 
you bravely paint two more yellow 
stripes right along the sides of the path. 
These two stripes are very interesting, 
because they are each parallel to the 
center stripe. You now have three lines 
stretching off down the road. Which 
one is the path line? 

Most people would pick the center 
line, which is fine. But does it much 
matter which one is the path line? If you 
say “I’m going to ride my horse and 
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follow the line on the left”, and I say 
“I’m going to follow the line on the 
right”, aren’t we both going to follow 
the path? Why, of course. 

We could even agree, if we liked, that 
the center line was the dividing line 
between the left and the right. We could 
call the center line “the starting line”, 
or “the main reference line”, or some 
similar concept, such as “the pre-emi- 
nent path line”. But the other two 
would still be path lines. 

In fact, if you brought enough paint 
with you, and if the farmers in the area 
didn’t come after you. with pitchforks, 
you could draw more lines on the grass 
next to the path, all parallel to the other 


three lines. If you drew carefully 
enough, (a tough job when you’ re walk- 
ing backwards through fields — through 
the corn-stubble and over the fences), 
you could paint several lines all the 
same distance apart. A whole bunch of 
path lines! Some are on your left and 
some are on your right. You could ride 
your horseand follow any of those lines 
and still follow the path (the same 
direction as the path). 

You could even number each line, 
using the center path line as a reference. 
The line on the side of the road to the 
right could be number one, and the next 
line could be number two, and then the 
third and fourth, etc. But how should 
we number the lines to the left? 

Well, if all the lines to the right are 
sequentially numbered starting with 
number one, then it is logical to call the 
main center line “zero”. And if the 
main center line is called “zero”, then 
it would make sense to call the first line 
on the left “minus one”, and the next 
line “minus two”, and then the “minus 
third” and “minus fourth”, etc. 

There would be several benefits to 
having these lines numbered in this 
fashion. Firstly, if you walked down 
the road away from the horse a few 
yards and turned around facing the 
animal, the lines on your right hand side 
are the lines which were previously on 


_ your left hand side. 


But with the new numbering system 
you don’t haveto beconfused. You can 
still point to a line and say “I'll follow 
line number four” and I would know 
exactly which line you meant. This is 
much better than saying “I’ ll follow the 
fourth line on the right” because that 
depends on which direction you are 
facing. 

Secondly, if you are riding along on 
number four, I know exactly how far 
you are from the center of the path, 
because if the lines are ten feet apart, I 
know you are forty feet away from the 
“zero path line”. 


Milestone Lines 

As we continue to prepare ourselves to 
ride along the path lines towards the 
mysteries of 3D thinking, we will sud- 
denly realize there’s something miss- 
ing. 

Regardless of which path line we 
follow, we won’t know how far we’ ve 
travelled. But we can invent a method 
to solve this problem. 

Striding back to where your horse is 
patiently standing, you can decide to 
draw across-line. This line goes side- 
ways, under the horse and across the 
fields, crossing all the path lines as if 
you were drawing a big tic-tac-toe 
game. Then, you walk down the path 
ten feet and start drawing another cross- 
ing line, parallel to the first. 

This acts like a milestone, because 
when you start to travel along the path 
line, the moment you arrive at the first 
crossing line you'll immediately know 
the distance you’ ve traversed (10 feet). 
If milestone lines are drawn every ten 
feet, then travelling past five lines means 
you have gone fifty feet down the path 
line. 


Altitude Lines 

If you are thinking “No — not another 
set of lines — I don’t want to hear it”, 
then your journey into 3D thinking is 


likely to be arduous for you, and creat- 
ing virtual worlds might not be your 
first choice for acareer. But just realize 
this: The path lines and the milestone 
lines are not sufficient by themselves to 
illustrate 3D space. 

Neither the path lines nor the mile- 
stone lines can indicate any information 
about altitude. For example, if your 
horse-riding takes you up a hill or a 
mountain, you won’t know how far up 
you have travelled unless you can draw 
some altitude lines. 

Of course, painting lines in the air is 
fairly difficult even with the finest 
quality paint. But, a computer can keep 
track of the altitude lines when we 
create a virtual space. 


How Is This Related To 
VREAM? (or, “Under- 


standing Grid-Lock”) 

When you begin the VREAM Develop- 
ment System software (which we intro- 
duced in Part 1), you are presented with 
a series of grid lines. This grid repre- 
sents the “floor” of your virtual world. 
(It isn’t the actual floor, because you 
can decide to place your floor else- 
where.) It is a reference grid, to assist 
you in your decisions about placement 
and size of objects. The importance of 
understanding how to utilize the grid 
becomes clear when you begin to create 
a virtual world. 

The grid is composed of ten lines. 
Five lines are drawn like the “path 
lines” described above — in the direc- 
tion of your view. The other five lines 
are drawn “across” the others, forming 
a grid. The altitude lines are invisible 
to you, but the computer keeps track of 
them. 

This system of grid lines is known as 
“Cartesian coordinates” , after the per- 
son whose name became synonymous 
with this method of thinking — Rene 
Descartes, a 17th century French phi- 
losopher, physicist and mathematician. 
He’s the one who said “I doubt, there- 
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tore I think: I think, therefore I am”. 
(Most people have heard only the sec- 
ond half of the phrase.) 

“Coordinates” are crossing lines used 
to determine a point. (The word “ordi- 
nate” comes from the Latin word 
“ordinatus”, meaning “ordered”, and 
“co” used as a prefix means “together” , 
so a “coordinate” is something that is 
“ordered together” .) 

That’s why we say “the coordinates 
of the point are 4,5”, meaning “four 
units over, and five units forward”, or, 
for 3D coordinates we say “the coordi- 
nates are 4,5,2”, meaning “4 over, 5 
forward, and 2 up”. These numbers 
have to be listed together in a certain 
agreed order, or sequence. 

The sequence which has been agreed 
to by conventional practice is (1) the 
path line number, (2) the milestone line 
number, and (3) the altitude line num- 
ber. This allows everyone to know 
immediately which direction is first, 
second and third. Also, by convention, 
these three numbers are called “x”, 
ON? ANG eZ rie 

So, “x” is what we call “how many 
path lines over”, “y” is what we call 
“how many milestones forward”, and 
“z” is what we call “how many altitude 
lines up”. Of course, we can use 
negative numbers to indicate counting 
in the reverse directions (eg. -4, -5, -2, 
would be the coordinates for “four to 
the left, five back, and two down”.) 


What Do We Do With The 
Grid? 
In VREAM, the grid is very useful in 
helping you decide what scale, or sizes, 
you want to have in your world. When 
the grid starts out, (the default), the 
lines are five units apart. You can think 
of them as being five feet apart. Since 
there are five lines on the grid, it spans 
20 feet (there are 4 spaces between 5 
lines). 

This gives you a lot of flexibility 
because you can use the grid to assist 


you in locating and scaling the objects 
you will create. For instance, if you 
want to create a wall, you can look at the 
grid and decide where your wall should 
start and how long it should be. 

For example, if you place your cur- 
sor where two lines intersect, you could 
locate the end of your wall there, and 
locate the other end of the wall where 
two other lines intersect, and you can 
quickly determine how long that wall 
will be by calculating the distance be- 
tween the lines (you know they are five 
feet apart.) 

But you can change the grid span. 
You can select the “Editor” menu, and 
click on “Grid” and “Grid Span”, and 
type in a new value. For instance, you 
may decide you want to change it from 
20 to 100. After entering 100, the grid 
is redrawn much larger, with the lines 
25 feet apart. Now, it is easy to 
construct a longer wall using the grid as 
a guide. 


Use The Cursor Position 


Mode, Also 


But the grid, as helpful as it is, is just 
one guidance tool. You also need to 
become acquainted with another tool to 
use in. conjunction with the grid. Push 
the F3 key and toggle to the “Cursor 
Position” mode. When you’re in that 
mode, the numbers in the upper status 
bar reflect the coordinates of the cursor 
position. 

You’ll see “W =” and three numbers 
(eg.5-W=-_ 5, 4, 2"). The “Ww” 
means “World Coordinates”, and the 
numbers tell you where the cursor is in 
terms of absolute world coordinates 
(there are other types of coordinates, 
too). 

Here’s how you use this information. 
Since the grid is located at an altitude of 
zero, if the cursor position is at “W= 
0, 0, 2”, then you know the cursor is 
located right in the x, y center of the 
world, but two feet up. To bring the 
cursor position down, watch the num- 


bers as you move the cursor towards 
you until the numbers say “W= 0, 0, 
0”. At this location, the cursor is 
positioned in the exact center of the 
world, and in the exact middle of the 
grid, and at the same zero altitude of the 
grid. 

I took a call once from a VREAMing 
friend who had created some objects 
while looking down at the grid from the 
top. When he moved his viewpoint to 
the front, the objects seemed to hover 
above the grid, and he wanted to know 
what he had done wrong. 

When I explained how to utilize the 

Cursor Position mode, he realized he 
had an incorrect perception of where 
the grid was without referring to the 
Cursor Position numbers, and found he 
was easily able to correct this percep- 
tion by using both tools together. 
As you gallop along, learning 3D think- 
ing, look for ways to use different 3D 
tools together to minimize your efforts, 
and practice putting the Cartesian be- 
fore the horse so your journey can be 
more enjoyable. 
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Company Profile 


C9HOESHSSSSHSHSSSHSHSHSOHSHSSSSSHHEHSTHHHSSHSSHESEHSHHSHSEHHOHHEHHSHSHEHEEE 





elcome to our first in- 
stallment of COM- 
PANY PROFILE. It 
is our hope that we 
can introduce you to some of the people 
and companies working in the Virtual 
Reality industry. We have adopted a 10 
Question format for this section. Our 
first company is Adams Consulting 
Group. 


Question 1: Please describe your 
primary business activity. 

Adams Consulting Group helps cli- 
ents implement Virtual Reality and In- 
teractive Multimedia Applications. Our 
services include: 


Needs Assessment - Analyzing the 
needs of the client company and assess- 
ing whether computer technology is the 
best way to address a given situation. 


Feasibility Studies - Researching op- 
tions for achieving the desired result 
and recommending the most cost-effec- 
tive approach. 


Media Selection - Choosing the best 
computer hardware and software avail- 


able for the client’s situation. 


Project Planning - Planning each phase 


Adams Consulting Group 
3952 Western Ave 
Western Springs, IL 60558-1042 


(708) 246-0766 
(708) 246-0971 (fax) 
Compuserve: 71052,1373 





of the project, including designing pro- 
gram specifications, developing pro- 
grams, selecting team members, test- 
ing, evaluation, and training person- 
nel. 


Project Management - Organizing and 
coordinating efforts of all people in- 
volved in the project. Problem-solving 
and strategizing improvements to the 
project plan, as needed. 


Program Design - Designing com- 
puter screens and software linkages to 
make the system easy to use, while 
accomplishing desired goals. 


Training - Developing and delivering 
customized training appropriate for the 
situation. 


Project Evaluation - Analyzing data to 
determine if the expected results have 
been realized. 


Question 2: Please describe the 
major players in your company and 
their primary functions. 


With over 20 years’ experience as a 
project manager, systems analyst, in- 
structional designer, systems engineer, 
and workshop facilitator, Nina Adams 


takes responsibility for all work com- 
pleted by Adams Consulting Group. 
Depending on the project, Nina calls on 
programmers, developers, program de- 
signers, instructional designers, graph- 
ics artists, composers, and video pro- 
ducers around the country to complete 
assignments using the best talent for the 
situation. 


Question 3: Please describe how 


the company was founded and the ma- 
jor steps that have led the company to its 
position today. 


Nina Adams has been involved with 
computer since 1966 when she was a 
Systems Engineer with IBM. Her ca- 
reer twisted and turned until she found 
herself working as an Instructional De- 
signer with a small consulting firm. In 
Sept., 1990 she decided to merge her 
interests by returning to graduate school 
to get a degree in “Motivation and 
Emerging Technologies: from DePaul 
University. She struck out on her own 
with Adams Consulting Group in Janu- 
ary, 1993. 

The major steps that have led the 
company to its position today are: 


* Spending many hours learning about 
Interactive Multimedia and Virtual 
Reality 
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* Getting name recognition by 

- Volunteering to be president of 
the Chicago Chapter of IICS 

- Starting the Chicago VR SIG 

- writing articles, and 

- giving presentations at SALT, 
Midwest Trainers Conference, 
Sig-Advanced Conferences, 
Meckler’s VR Conferences, etc. 


* Caring about other people and their 
success 


* Acting ethically in all my relation- 
ships 


* DELIVERING MORE THAN THE 
CLIENT EXPECTS AND DOING 
WHATEVER IS NEEDED TO GET 
THE JOB DONE! 


The pitfalls of starting Adams Consult- 
ing were the same as those of most new 
companies: 


* How do you find the people who need 
your services 


* How do you continue marketing so 
you can get more work when you’re 
working on client contracts 


* How do you maintain any balance in 
your life 


The high-point was landing the first 
contract with Anderson Consulting. 
Having Anderson Consulting as a client 
increases your credibility and makes it 
a lot easier to land other contracts. 


Question 4: what do you feel is 
the major strength of the VR Industry 
and why? 


The major strength in the industry 
today is the thought that anyone can 
succeed and there are many people 
trying. How many new VR related 
businesses have developed in the last 2 
years? How many people are working 


in small groups hoping to become the 
next Microsoft? 
In this business, you don’t have to 


- have athletic prowess. You don’t have 


to be able to perform in front of a 
camera. You have to have great ideas 
and dedication. 


Question 5: what do you feel is 
the weak point of the VR industry and 
why? 


The weak point in the industry is the 
media hype. People at trade shows put 
on HMD’s and expect HDTV. If 
Pacman was successful, many VR ap- 
plications can be successful. But, ex- 
pectations need to be managed. 


Question 6: what do you see in 
the next 5 years for your company? 


During the next two years, I see a 
growth in Interactive Multimedia de- 
sign projects and VR feasibility studies. 
Three to five years out, I see a growth 
in corporate VR development projects. 

I don’t foresee any change in the 
company structure in the next two years. 
Until about three years ago, most major 
companies didn’t want to hire a small 
company. But now, the major compa- 
nies realize that a small company can 
deliver good products at lower costs 
than large companies since they don’t 
have as much overhead. If this trend 
continues, Adams Consulting will con- 
tinue to work as a “virtual corporation” 
and hire cyber-cowboys on a project by 
project basis. 


Question 7: Where do you feel 
the “big explosion” application wise 
will occur and why” 


HOME ENTERTAINMENT. Look at 
the past: Radios, TV, VCR’s, Sega, 
Nintendo. Even the computer industry 
has exploded because of its home use 
for computer games. 


Question 8: what is it going to 
take for Virtual Reality to become as 
popular as,say, Nintendo? 


Lower cost, better HMD’s, a great 
game, and lots of advertising. 


Question 9: Do you feel there is 
areal need for VR in business and why? 


If depends on the company. Some 
companies will really need VR. Others 
may not. 

A company that needs a “leading- 
edge” image may need VR to maintain 
that image. 

A company may find that a VR 
application is the best way to train an 
employee without risk. 

At some point, VR may become as 
prevalent as desktop computers. But 
remember, there are still a number of 
major corporations whose employees 
don’t all have desktop workstations 
even though many corporation think 
they can’t live without them. 


Question 10: Do you feel it is 
true that VR is a technology which 
provides a solution even though we 
don’t know what the problem is? 


I think that depends on who you ask. 
If you ask Dave Warner of Loma Linda 
Hospital, he’ll show you many prob- 
lems which VR is solving. 

And, even if we don’t know the 
problem, is that so bad? Did people 
think we had a problem to be solved 
when the telephone was invented? When 
the automobile was invented? When 
TV was invented? Even the “Post-It” 
was invented without a direct problem. 
It wasn’t until the technology was built 
that people could apply the technology 
to an existing problem. 
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The Disk 


As you may have already noticed, this issue of PCVR Magazine does not have a disk enclosed. 
We are getting rid of the disk and replacing it with a BBS. 


There are two important reasons for this decision. 

The first is that we can now offer the most up-to-date version of programs that appear in the 
issues. A case in point. The code for the Logitech Cyberman that appeared in Issue 12 has 
three bugs in it. Although they take about 1/2 a second to fix, the bugs were not found until 
after the disks were sent. We offer the fixed version on the BBS. 

The second reason for tossing the disk is the size. Most people wanted a 3 1/2" disk. We did 
not see any way of offering this disk size in the near future so this combined with the first reason 
led us to start our own BBS. The number is (608) 877-1017. The BBS has one line that is 
answered by a 14.4K baud modem and is operational 24 hours a day. 


In addition to the disks, there are numerous programs on the BBS. For example: 


DOOM is available. This is the next generation Castle Wolfenstein. It is over 
2 megabytes compressed. 


ACK3D is a toolkit for those who want to write Wolfenstein-type games. 
POV-RAY 1.0 and 2.0 are top-notch ray tracing programs 
Numerous objects files. 


The complete archive of the USENET group sci.virtual-worlds is available. 


So give us a call and enjoy. 
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It’s interesting to see how the media’s attention toward VR has changed over the past year. 
Toward the beginning of 1993, the media still had a glossed over view of what true Virtual 
Reality was really all about. There was significantly more hype than truth. 


But at the end of the year, things have changed. I recently saw a program called The Next Step 
on the Discovery Channel. By far one of the best channels on cable in my opinion. The show 
included a 15 minute or so spot on Virtual Reality. As I began to watch the program, I was 
ready to ignore most of it and be disappointed. Much to my pleasure, the show was very well 
done and really represented the state-of-the-art in Virtual Reality. 


: A good portion of the show was on the software WorldToolKit from Sense8. They showed the 
company's offices and different ways the software can be used. At several points, they went 
over to the offices of the CyberEdge Journal. For those unaware of this journal, it is dedicated 
to providing news about the Virtual Reality industry and is published by Ben Delaney. For more 
information call: 415-331-3343. Subscriptions are $129 per year. 


I was even more surprised when the program started to interview Ben himself. Now, I wasn’t 
surprised because it was Ben but because the program was getting to the heart of the VR 
community. There were no scientists in their lab coats but real people. So maybe Virtual Reality 
will get some respect after all. 


As you may have already noticed, PCVR Magazine is undergoing more construction. All of 


the changes are in anticipation of the magazine being printed by an outside source. If you have 
any comments, please let us know. 


Joe 
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Electronics . 
Surplus City 


BBS On-Line Store Inventory (310) 217-1922 
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Call for additional bargains. New inventory added daily * We are interested in purchasing articles and project ideas for our new magazine! 


Brand new, 3.5°, Fuji FK309-26 .. $29.00 





FLOPPY DRIVE New, 360K DSDD $9.95 
Specify black or beige bezel 
XT Motherboard 8 Slots, 8 Mbz. ............ $16.95 


FLOPPY DRIVE CONTROLLER ......$21.49 


1.44MB/1.2MB/720KB/360KB FDC (for 8088, 286, 386). 
These will fit in XT as well as faster machines. They control 2 drives. 


MICROCONTROLLERS EPROMS 

| ae $5.00 F764 scccssssesescessacasserse 9 

21 | | ee $8. DIN 2B cer scesnsensscves $2.50 

Ce nn $4.00 27256 oo. eccssean .00 
$2.00 270100. .00 










- .$32.00 
Irwin Model 245 40meg 
Brand new, will store 80 meg w/compression, interface to floppy controller 


LASERS 
Lasers 3-4 MW HENGE .......ecescssescsesteeeeeseeeeeees $24.95 
Lasers 4-5 MW HENG ..........c.csscsesesseeeeeseeeeeees $35.95 
Laser Deck 10 Mw HeNe Laser .................. $199.00 


Power supply, 2 beam splitters, 5 front surface mirrors, AO modulator, AO 

driver, polygon scanner, photo detectors, 3 special lenses, polarizer, over 

$5,000 worth of optical components plus documentation. Sold many 

these to Fortune 500 companies, universities, and research labs. Applica- 

tions include research, design and engineering. An experimenter's dream. 
Visible Laser Diodes (visible red light) 


HIMWiee eee $15.00 2Mw.. i. $23.95 

Laser DiOdet es sees-sc. eon ee seca $15.00 
5mW, by Toshiba, brand new, TOLD9200, without focusing lense 

Basel Ode) Kit ei.3.t0; ccsecceresesteresceese cee $49.00 
To power TOLD9200, includes laser diode, board, parts, instructions 

LASeMMUDESt ee ea eee $39.95 
From SIEMENS, brand new, 5mW HeNe 

SOLID STATE RELAY .......................... $8.95 


Cryon 01240, input 3-32 VDC, output 120 VAC 40A 
MOS Fet N-Channel ar #sesP222 sov 104 ...4/$1.00 


Controllers 
BME FUN BORED scs.iscssusesisveusesanrsnesincndas $99.00 
Proteon Pro-NET-~4 Model 0P1347, 4 Mhits 


















Come into Our Mane | ys We fey 


AST FOUR-PORT/XN 


UARTS socketed (16450's) DOS & Xenix drivers .... $29.95 


IG MEMORY CARD... $99.00 
Buffalo RJB-1000, SCRAM card - 1 Meg PC-MCIA 2.0 JEIDA SCRAM Memory 
Card by Melco Inc. Type 1 card, thinnest to fit type 2 or 3 slots. Will fit device 
Meeting standard: HP95LX, Sharp, NCR, etc. Elsewhere for $150. 

Our price is BELOW WHOLESALE! 


BABY “AT” CASE 8 Siots...................4.. $37.00 
With hardware and 150W power supply 

FULL HEIGHT “AT” CASE ................ $45.00 
By Wang Microsystems, 230W power supply 

CGA VIDEO CARD py Paradise ............... $19.95 

ADAPTOR KIT For Hard or Floppy Drive ... $3.00 


(3-1/2" drive in 5-1/4" slot) with hardware & cable 


Floppy Disk Controller Board .. 
Dual, 360K or 720K switch selectable 
Async Cluster Adapter by AST .................0.. $34.95 
Multichannel board providing 4 individually addressable RS-232 serial 
ports on IBM PC/XT/AT. (Asynec Cluster Adapter Cable add $5) 

CCD SCANNER BOARD ..................... $24.95 
Uses a 4096-element line imaging chip. Can use for robotics, astronomy, machine 
vision, high resolution slow scan TV, etc. Supplied with documentation. 

50-Watt Switching Power Supply ...................... $14.95 
Astec Model #AC9232-01 for microprocessor-based systems, disk drive systems, 
terminals & mixed logic. 5 VDC/6A, +12 VDC/2.5A, -12 VDC/0.5A, -SVDC/05A 

STEPPER MOTOR ...................0...00.0... $19.95 
by Oriental Motor, Model #PH566-A-05, high precision, 500 steps per rev., 
0.72° per step 

Monitor Board with Power Supply .................000.. $7.95 
High voltage, video, brightness, focus, vertical and horizontal 
with flyback transformer. Model 99-0493-001 rev D. 


PC Mother Board by Hyundai ................0.000000. $13.95 
With serial, parallel, floppy controller. Space for 512K memory on board. 










COD or send Cashier's Check or Money Order to ECSC 


1490 W. Artesia Blvd. * Gardena, CA 90248 
Orders only (800) 543-0540 - FAX (310) 217-0950 
Tech Support & Info (310) 217-8021 


$20 minimum order, CA residents add 8.25% sales tax. 
Prepaid: We pay shipping in Continental U.S. on orders up to $100. 
Over $100 add $10 shipping and handling. Laser deck 
$20 shipping and handling. COD: You pay shipping + $4.50 UPS COD charge 










































Create a Virtual 
World with the 
VREAM 3D World 
Editor. 


Make changes to 
the Virtual World 
with the VREAM 
3D World Editor. 


Enter the Virtual 
World with the 
VREAM Runtime 
| System. 


Roam freely 
through the Virtual 
World in real time. 


Grasp objects in 
the Virtual World 
with the user 
controlled hand. 


Move objects 
throughout the 
Virtual World. 


Affordable, Textured, Fully Interactive Virtual Reality for the PC... 


VREAM 


Virtual Reality Development System 








True Virtual Reality for the Consumer Market 
* VREAM is an affordable, complete, off-the-shelf VR System 
¢ Runs on an IBM compatible PC with a standard VGA graphics board 
* Contains a complete graphical user interface 
* Generates fully interactive, textured VR worlds without programming 


A Complete Solution for Developing Virtual Worlds 
Contains all of the elements you need to create fully interactive, 
textured virtual reality worlds on a standard PC 
The VREAM 3D World Editor allows you to create your virtual world 
by drawing the objects that comprise your world in 3D space, and then 
defining attributes for those objects (sound, motion, weight, etc.) 

The VREAM Runtime System allows you to walk through and fully 
interact with your virtual world 

The VREAM Scripting Language allows you to optionally define the 
virtual world in script form within a standard text file 

The VREAM Documentation includes over 1000 pages of system 
information, sample worlds, and a complete tutorial 

No need to purchase expensive supplemental software like 3D 
modelers, compilers, linkers or DOS extenders 


Create Fully Interactive Virtual Worlds 
Walk through your 3D virtual world in real time 
Grasp, move and throw objects in 3D space 
Assign attributes to objects in the virtual world like sound, motion, 
weight, and elasticity 
Define customized object links, allowing the user's actions to 
dynamically update object attributes 


Create Desktop VR or Fully Immersive VR 

* VREAM allows you to create device independent virtual worlds which 
will support a full range of interface devices connected to your PC 

* A standard keyboard, mouse, joystick and computer monitor may be 
used to experience desktop virtual reality applications 
High-end interface devices like head-mounted displays, 3D tracking 
systems, 3D mice, 3D ball controllers and gloves may be used to 
experience fully immersive virtual reality applications 


Many Advanced Features 
Apply photorealistic textures to objects in the virtual world 
Generate monoscopic or stereoscopic views of the virtual world 
Create objects with hierarchical rotations and translations 
Create, change, save & delete objects within an executing virtual world 
Launch external PC applications from within a virtual world 
Link together multiple environments within a virtual world 


Complete Virtual Reality Development System only $795.00 
Runtime System only $59.00 
Advanced Runtime System only $295.00 








For more information on the VREAM Virtual Reality Development System, 
please contact your local computer software retailer or contact us directly at: 


VREAM, Inc. 
2568 N. Clark St. #250 Chicago, IL. 60614 Phone: (312) 477-0425 Fax: (312) 477-9702 





VREAM is a registered trademark of VREAM, Inc. IBM is a trademark of IBM Corp. 











